Software policies should read the same, whether open source or proprietary

Open source software policy is better without open source

Subscribe now

Get the highlights in your inbox every week.

Here’s a fun experiment (if, like me, you’re a huge nerd): take an open source policy from your agency, company, whatever, and strike out the words "open source." Bam, you now have a much more sensible and reasonable "software" policy.

When the OMB and DOD declared open source software to be "commercial software," it wasn't a bureaucratic trick to legitimize open source. They meant it quite literally: software is software, and whether it was developed by open source, a proprietary company, or a team of monkeys, all the same rules apply. So if you're writing an "open source software policy," why not write a policy for the rest of the software world while you’re at it?

Let's take IRS' guidelines for using open source software. There's some good stuff in here, and long-debunked myths as well. All this can be fixed by striking the words "open source," turning the document into a "software policy" instead of an "open source software policy."

Let’s get started:

Open source software, while it can be useful in many instances and appear to be cost effective, may present a security risk because open source developers don’t typically follow security best practices when developing their software.

When I read this, my jaw dropped. We can argue about whether open source is a more secure model for software development (which it is, just ask Bruce Schneier) but we can’t summarily declare open source developers "typically" less concerned about security. That’s silly. Some of the most-reviewed, most-secured software is open source. Some of the finest minds in security are open source developers.

Also, it’s not like proprietary software is magically more security-conscious. Proprietary developers can be sloppy, companies can have poor development practices, and it’s just as likely that a bad actor will work for a proprietary software company as contribute to an open source project.

With that in mind, we can take out the words "open source," and the sentence is suddenly much more reasonable.

Additionally, support for the open source software is not always provided by the vendor, and open source vendors can be slow to respond to identified flaws in their applications with a security fix.

I work for an open source software vendor, and this is news to me. Our track record is actually stellar. I've seen no evidence and can think of no earthly reason why open source vendors would be slower to identify and respond to software flaws as a class. Again, generalizations like this are silly.

The underlying concern, though, is valid. Unsupported software presents a risk. Poor support is almost worse—think of the hours we’ve all wasted with an unqualified or unresponsive support operation. This isn’t specific to open source. Bad support is bad support, no matter how the software was developed.

Again, take out "open source," and this becomes much more accurate, and a lot less FUD-y.

Additionally, many open source software products are part of an open community that allows anyone to contribute updates and bug fixes, which isn’t always done with security in mind, so the onus is on the distribution channel to validate releases.

I’m starting to call this the "Wikipedia Myth." This clause makes it sound as though open source software is freely editable by anyone with an email address. This is obviously not the case, as anyone who’s worked with open source can tell you. Open source communities have elaborate systems for code review that can rival what's in place in proprietary development shops.

Again, though, the underlying concern is valid and the remedy is sensible. If you’re concerned about the integrity of your software, you should get the software from someone you trust.

When deciding to procure open source software, the agency should seek companies that will provide software support, and consider the cost of potentially having to pay a third-party to support the software by issuing security patches and bug fixes if direct support from the software vendor is not an option.

This clause make a lot of sense. You don’t want to run unsupported software. You want to be able to call someone to tell them about a problem, and you want them to respond promptly. The authors had open source in mind, but the need is just as strong for proprietary software. What happens if your proprietary vendors goes out of business? What if they get acquired? What if the product is discontinued? Again, the problem and the remedy apply to proprietary software just as easily as they apply to open source.

The agency should also consider the open source software's ability to comply with IRS Publication 1075 security requirements. For example, any software that will transmit federal tax information (FTI) must encrypt the FTI using a FIPS 140-2 compliant encryption module that has been validated through the NIST Cryptographic Module Validation Program (CMVP).

Here's another clause that makes sense. The IRS has a non-negotiable need for security certifications like FIPS 140-2, and any software must comply with those requirements. That's true for proprietary and open source alike.

IRS Safeguards recommends any agency considering the use of FTI in open source software mirror the IRS policy that is used internally at the IRS to govern the use of open source software. The IRS Policy in the Internal Revenue Manual (IRM 10.8.1.4.4.1) is that open source software can be installed on IRS systems if it is—

Adheres to a secure configuration baseline checklist either from government, industry or the software vendor

Agreed! It’s actually kind of funny that once you get through all these concerns about open source, the actual policy only requires that you adhere to the terms of the license, configure it properly, and get approval from the IT department. Just like proprietary software.

So here's the "de-open source'd" version, which I think reads much better:

Open source sSoftware, while it can be useful in many instances and appear to be cost effective, may present a security risk because open source developers don’t typically follow security best practices when developing their software. Additionally, support for the open source software is not always provided by the vendor, and open source vendors can be slow to respond to identified flaws in their applications with a security fix. Additionally, many open source software products are part of an open community that allows anyone to contribute updates and bug fixes, which isn’t always done with security in mind, so the onus is on the distribution channel to validate releases.

When deciding to procure open source software, the agency should seek companies that will provide software support, and consider the cost of potentially having to pay a third-party to support the software by issuing security patches and bug fixes if direct support from the software vendor is not an option.

The agency should also consider the open source software's ability to comply with IRS Publication 1075 security requirements. For example, any software that will transmit federal tax information (FTI) must encrypt the FTI using a FIPS 140-2 compliant encryption module that has been validated through the NIST Cryptographic Module Validation Program (CMVP).

IRS Safeguards recommends any agency considering the use of FTI in open source software mirror the IRS policy that is used internally at the IRS to govern the use of open source software. The IRS Policy in the Internal Revenue Manual (IRM 10.8.1.4.4.1) is that open source software can be installed on IRS systems if it is—

Topics

About the author

Gunnar Hellekson - I'm the Chief Strategist for Red Hat's US Public Sector group, where I work with systems integrators and government agencies to encourage the use of open source software in government. I'm a founder of Open Source for America, one of Federal Computer Week's...

Exactly right, they just need one "software" policy. As a case in point when I worked at an aerospace firm several incidents highlight the importance of what you have said.
First, considering code escrow agreements we had two cases where we should have been protected by our agreements. In one the fact another party bought the IP of the troubled company and barred the transfer of code because they claimed they would support it. They did not and we never got the code. Second incident, we got the code but magic build knowledge was required and we could not actually build the software.

When considering vendor support know that having a real "commercial vendor" does not equate to actual support. We were using an RTOS from one of the major vendors and had a critical bug in the Ethernet stack that would crash the machine frequently (on a production machine that was running production cycles that could be half a day or longer) We could not complete a production cycles and a multi-million dollar investment was worthless until the machine could run. We did find a workaround that let us run by disabling partial functionality. This was fortunate because the vendor:
a. Refused to acknowledge the bug existed for four years despite complete documentation including traces showing exactly where the bug occurred.
b. Took an additional 4 years to actually fix the bug after they acknowledged it.

In any case we have always found that any analysis for software acquisition should include a section for risk mitigation. It seems obvious but is (very) ofter skipped in the "real" business world. In my analyses Open and Libre Source software is considered a strong risk mitigator. We have never ended "up a creek without a paddle" in projects with open source like we have when using "professional/commercial" vendors.

Because complying with software licenses (whether open source or commercial) is critical to any organization, Entente has developed a hosted license tracking system, IPCompass, that tracks the licensing and use details for all your inbound components.

Footer

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.