Skip to content

Can Openness in the US Government Lead to Better Application Security?

    
Can Openness in the US Government Lead to Better Application Security?

white-house-application-security.jpgOn Tuesday morning, ZDNet reported that U.S. government has published a new federal policy that aims to encourage more agencies to open-source custom code they’ve developed. 

According to the piece, the policy draws attention to the waste that occurs when agencies purchase substantially similar code because other agencies haven’t made their code discoverable or available.


Point-of-View by Jeff Williams

How does this policy’s focus on “needing to factor reuse into any new custom software project” tie into the idea that code will be used in ways that developers cannot anticipate?


In principle, I really like this idea.  I fully believe that openness can lead to better security.  In government this is doubly important, as we all have the need to trust the software used to govern.

In cryptography, Kerckhoff's Principle says that cryptographic software should be secure even if the software, algorithm, cipher text, and plain text are all available to the attacker.  I believe this is true for all software.  This is why you can use FreeBSD safely even though the attackers have all the source. 

Take voting software, for instance.  It's currently closed, difficult to audit, and people are strongly motivated to "influence" the election.  What if the manufacturer pulled a "Volkswagen" and decided to work properly when tested, but in a real election it favors one candidate or party. How would anyone know?

However, I'm a little skeptical about the drive to share.  Most software isn't designed for reuse...particularly software written under contract for a specific agency.  Contractors may inadvertently be influenced to make their code *less* reusable!  They get paid to write new code remember. Government software is in desperate need of security. I think this helps.  If nothing else, this creates an incentive not to be embarrassed.  Mudge's new software labeling project has the same effect. Still, even though many eyes make all vulnerabilities shallow... Getting those eyes isn't guaranteed.  It might not even be possible.  Many projects to audit open source code have failed.  It's a lot of work.  Perhaps the qualified reviewers are doing paid bug bounties? Wonder if that's coming next.

Ultimately, open source projects only succeed when you build community around a piece of software.  I've had some that worked big, and a bunch that never caught on.  I don't see a plan here to make it fun.  Why would I look at software for HUD and contribute to make it better?

So, to me, this is one good step on a long hike.  Welcome to 1998, Government! 

 ~ Jeff Williams, CTO
Contrast Security 
Security
 


continuous-application-security

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.