Application Security

Securing Open Source App Development

IT and IT security governance in California's state governments are decentralized, but that doesn't mean that the central authority isn't actively engaged in making sure what needs to get done gets done.

Earlier this year, the state chief information officer and chief information security officer adopted standards to govern how state employees and contractor should use open source software.

And, in an interview with GovInfoSecurity.com, (transcript below) California CISO Mark Weatherford said the departments and agencies self regulate themselves on implementing the new standard with oversight from above.

"My office gets involved at a high level, to insure that the security folks and security staff in the different agencies, where the development and where the tools are being used, are involved, to make sure that at that level, that they are engaged in any kind of review," Weatherford said. "As projects go forward, we get engaged early, hopefully, so that we can understand how the projects are being developed, and who the different players are, so that we can ensure that the right people are at the table as these projects go forward."

In the interview, Weatherford also addressed:

  • Why California implemented the open source standards now,
  • The role economics played in adoption of the policy, and
  • Security concerns of using open source software.

Weatherford was interviewed by GovInfoSecurity.com's Eric Chabrow.

Check out previous GovInfoSecurity.com interviews with Weatherford:

ERIC CHABROW: Earlier this year, the State of California issued a policy letter which formally establishes open source software in state government, as an acceptable practice. Why was the policy letter issued, and why now?

WEATHERFORD: People have been using open source for years, and it's kind of been the unspoken rule that a lot of people use it without having formal policy around it. So, we just decided to go ahead and formalize that, and issue a policy for it. We do a whole lot of development in the state, and reusing code and using some of the other things that are out there that are well tested and validated just seems to make a lot of sense to me.

CHABROW: In developing the policy, what information security factors were considered?

WEATHERFORD: The biggest part of that will be, obviously, a review of the code, to make sure that it is, in fact, validated and appropriate for where it should be used. But, for the most part, my input into it was the use of the tools and security software that are out there that are, really, the de facto standards in the industry right now.

CHABROW: You said that a biggest part of this would be the review of the code. Now, if I recall, you have a decentralized approach to information security in California. So, who would be conducting these reviews?

WEATHERFORD: That's a very key part of this. And you're right, we are very, very decentralized. The whole goal is, as we are developing, my office gets involved at a high level, to insure that the security folks and security staff in the different agencies, where the development and where the tools are being used, are involved, to make sure that at that level, that they are engaged in any kind of review.

CHABROW: In California, would those people self-regulate themselves?

WEATHERFORD: To a certain extent. But, as I said, getting my office involved, and getting the office of the CIO involved is becoming pretty much the norm now, as projects go forward, we get engaged early, hopefully, so that we can understand how the projects are being developed, and who the different players are, so that we can ensure that the right people are at the table as these projects go forward.

CHABROW: In developing this policy, how much did economics play? We all know the kind of financial struggle that California and other states are going through at the moment.

WEATHERFORD: Obviously, economics is a big part of it. Reusing things that are already out there and already well-established makes a lot of sense. It costs a lot of money to spend time developing code and developing tools, so, sure, the economics plays a big part in that.

CHABROW: You wrote in your own blog a few months back, "It seems to me that thousands of developers and hackers beating up on open source code is a pretty efficient and transparent way of identifying software bugs and vulnerabilities in open source software, kind of like software market Darwinism, where the strong survive." What, if anything, gives you pause about using open source software, from a security perspective?

WEATHERFORD: Boy, I didn't know I said that. That sounds really smart, doesn't it?

CHABROW: [Laughs.]

WEATHERFORD: You know, I would say what gives me pause is the fact that sometimes people may not vet the code well enough before they use it, or vet, you know, when they bring the software in, and somebody finds something that does what they want it to do, and condense and concise, and they may not give it the appropriate review that they should have. That's the one thing that gives me pause. Because, as you know, sometimes what you get is not what you expect. And it can be a good thing, I guess.

CHABROW: And what's been the response to the policy?

WEATHERFORD: Here in the state, it's been really good. You probably read on my blog, probably one of the highest reviewed blogs that I've written, and most of the responses have been something to the effect of, "Wow, it's about time, and government is finally coming into the 21st century." I am a fan of open sourcing. Some of the best tools that we use in the security business are, in fact, the standards, and they're open source. For us, this has just been a good, good thing, to formalize the implementation and use of standard security tools.

CHABROW: If I understand it, these have been used for many, many years in California, it's just a matter of you having some kind of rules to make sure they are applied properly.

WEATHERFORD: Yeah, and a lot of people have been using some of these tools for years. I don't know anyone who doesn't use some of these tools, quite frankly. And just because they are standards. So, yeah, we're just, we're modifying it and formalizing the use of them.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing govinfosecurity.com, you agree to our use of cookies.