DZone
Performance Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Performance Zone > Can Openness in the US Government Lead to Better Application Security?

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

How does a policy of code reuse tie into the idea that code will be used in ways that developers cannot anticipate?

Jeff Williams user avatar by
Jeff Williams
·
Aug. 16, 16 · Performance Zone · Opinion
Like (1)
Save
Tweet
2.88K Views

Join the DZone community and get the full member experience.

Join For Free

white-house-application-security.jpg

On Tuesday morning, ZDNet reported that the 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.

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 a 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! 

security Open source Software application

Published at DZone with permission of Jeff Williams, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Leverage Speech-to-Text With Node.js
  • Fun With Modules
  • Back to Basics: Accessing Kubernetes Pods
  • Why Should You Choose ReactJS for Your Next Project?

Comments

Performance Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo