Slashdot Mirror
White House Releases Federal Source Code Policy To Help Government Agencies Go Open Source (whitehouse.gov)
dwheeler writes: The U.S. federal government just released a new Federal Source Code policy (PDF). For each of the next 3 years, at least 20 percent of custom-developed Federal source code is to be released as open-source software. Earlier this year, Tony Scott, Federal CIO of the U.S. government, wrote on the White House blog that the U.S. government "can save taxpayer dollars by avoiding duplicative custom software purchases and promote innovation and collaboration across Federal agencies." Today, they released the Federal Source Code policy. TechCrunch reports: "The main requirement is that any new custom source code developed 'by or for the Federal Government' has to be made available for sharing and re-use by all Federal agencies. For example, this means that the TSA can have access to custom made software that was commissioned by the FBI. Considering there is probably a great deal of overlap in applications needed by certain branches of the Federal Government, this rule alone should save the government (and taxpayers) a great deal of money. In fact, the policy states that 'ensuring Government-wide reuse rights for custom code that is developed using Federal funds has numerous benefits for American taxpayers.'"
I, the taxpayer, paid for it and demand that it's open. If it gets attacked, it will be fixed.
Security through obscurity is a phantasm. But closed source companies (and their sympathizers) continue to tout it.
This is not to say that open source has had no vulnerabilities. But far fewer than closed source, albeit closed source has more attackers.
The source code should be secret, which will help keep out hostile countries.
Obscurity is not security. I'm more comfortable looking at a disassembly than I am with source code. The disassembly doesn't lie.
I'm a white hat, for the record. It's my job to help people, not inconvenience or hurt them.
I'd prefer it if trolls were hunted down by hungry dogs with steel fangs, castrated, and then sent to work in coal mines without air filters.
I guess neither one of us is going to get what we want.
The world's burning. Moped Jesus spotted on I50. Details at 11.
IME, writing code that is reusable is quite hard. Getting it into a form that using it in another project is worthwhile is costly. It'll be interesting to put in a FOI enquiry in a few years to see whether the benefits outweigh the costs.
I'd really prefer that federal agencies be secure against hackers. If they use open source, hostile countries like Iran and North Korea will be able to look for vulnerabilities in the code and more easily hack into the federal government. The source code should be secret, which will help keep out hostile countries. Security should be the primary goal, and therefore the source must be closed.
All this means is that you don't understand software security. There's no guarantee that open source is free of security issues, of course. But at the very least, it does mean that you're not depending on some "secret" in the code to remain secure, which is NOT any sort of security at all.
The most widely used security algorithms in the world are open specifications and have open source reference implementations, in case you aren't aware. These algorithms and implementations can never be proven secure except by their resistance to determined attacks over time, and this can only occur when they are publicly available for researches to work on ways to crack them.
Irony: Agile development has too much intertia to be abandoned now.
Public software from public money. The model works well for scientific software at NASA, ESA, CSA, etc.
Big problem here: a lot of software where the functionality could be reused can't be reused because it wasn't written for reuse. It'll have a lot of instance-specific code scattered throughout, for example logging functions that're specific to the system it was first written to run in. The result is it's easier and faster to write it from scratch than to try and remove the instance-specific code from the original source to make it suitable for use somewhere else. An open-source policy doesn't need just a mandate for reuse, it needs a mandate for making software reusable at the time it's written. That, unfortunately, is something any developer can tell you is really hard to get management to agree to.
I don't honestly care if the software is open source, use what works best regardless of whether RMS approves or not. What I really want to see instead is publicly accessible document management for the laws and regulations. I want to be able to determine exactly who entered in every single word, made every single edit, and when they were committed to the document. No more "I don't recall who added that" or "I have no idea who made that change". And make sharing a login a felony, so a member of Congress can't give out their login credentials to their entire staff and then disavow personal responsibility. If someone pastes in 5 pages from a lobbyist late at night hours before the vote, I want to know precisely who did it and under what circumstances. Full transparency, right down to the single word or punctuation mark. The technology is cheaply available right off the shelf, they could implement GitLaw across the entire government by year's end for less than they spend on lawyers to defend FOIA lawsuits in a single quarter.
You're just jealous 'cuz the voices talk to *me*
From: https://18f.gsa.gov/2014/11/26...
Security and open source
"System security should not depend on the secrecy of the implementation or its components."
-- Guide to General Server Security, National Institute of Standards and Technology
A codebase is a terrible secret.
Because a codebase is so large, it cannot easily be changed. Furthermore, it must be known, or at least knowable, to the large number of people who work on it, so it cannot be kept secret very easily. This is represented at the bottom of figures two and three. Therefore "security through obscurity" is a terrible idea when it comes to a codebase. In most cases your system will consist of code which you reuse as well as code that your write yourself. Therefore both of these types of code should be open.
Of course, your system will have secrets in most cases -- keys, passwords, and the like -- but you should assume they have been discovered and change them often. We call these secrets a "red thread", because, like a red thread in a white handkerchief, they should be as vivid and thin as possible. By making them thin, such as a single password, you make them very easy to change and keep secret. Although these secrets are tiny, they must be managed carefully and conscientiously. We believe this concept is so important that we have placed it on our reusable version of the Wardley-Duncan map linked to above.
There are risks of defects and complexity associated with using open source modules indiscriminately. There are also security vulnerabilities to any system, either through negligence or by the intention of a bad actor. The key to preventing this is code review.
You must make sure that each component you use is code reviewed. In practice this means either that you must use very popular projects whose code is looked at by a large number of people on a regular basis, or you must use small projects which your team can code review itself. In practice, the criteria for making this decision for reused components is similar to the rules of thumb that we have already laid down for managing risk.However, you may need to adjust these rules of thumb based on how often you plan to update the component.
For example, a small component which is very stable need not be updated at all. If it is small and you can code review it or pay a team to code review it, then you may use it. On the other hand if the project has frequent updates, your team will have to decide how to manage these updates. A large project may have both stable and experimental branches. In general your team will want to update as frequently as the major number of the branch. If the project is very active and many people are looking at it, this does not represent a security risk. If however a project is changing rapidly and producing many releases and your team does not have the resources to ensure that each new release is code reviewed and you do not trust the community to do so, then you probably should not use that component.
With an open source component, it is at least possible to understand how much code review it is receiving.We know of no way to do this for closed source code kept as a secret.A firm which is asked to maintain the security of the code that it has written is placed in a conflict of interest. It isn't in its short-term interest to spend resources on this code review, and it is not in its short-term interest to admit defects.
Security of your own code
Make all your code open and examinable from the start. Moreover, it is best to encourage as many people to look at it, because the more people who seriously review the code the more likely a security flaw is to be found. Programmers will code more securely when their code is in the public's eye from the beginning.
Code that you write or contract to have written should be open source from the start, because it relieves you of the terrible risk and burden of maintaining the secrecy of the codebase. This means not only that it is published under an open source license as explained in our open source policy, but that it is published in a modern source code control system.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
From the first link (PDF):
SUBJECT: Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software
to release at least 20 percent of new custom-developed code as Open Source Software (OSS) for three years
develop an open source software policy that, together with the Digital Services Playbook, will support improved access to custom software code developed for the Federal government
and several other instances of the term.
Also, under the first heading "Objectives" it clearly speaks to sharing code with the public as well:
Establish requirements for releasing custom-developed source code, including securing the rights necessary to make some custom-developed code releasable to the public as OSS under this policy's new pilot program;
Did you even try?
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
Wouldn't it be dependent on the project, the maintainers, the organization, the feedback mechanisms and the underlying structure of the code to begin with?
Or should we get into a "Which is better, Chocolate or Vanilla?" thing.
Open source projects managed by systems like GitHub and forums are often maintained very well. But there are hundreds of projects placed into the open source that are left floating with no support for every one project which actually has a support infrastructure.
Federal contracts work in such a way where the code will now be made open (at least within the federal government) and once the contract is half way done or delivered, the contractors will be moved to something else and the code will die a slow painful death with no support.
Closed code itself isn't more secure than open source. They are exactly the same. It's how well they were made and how well they were maintained that matters. What really matters is whether there's an organization that is supporting the product open or closed. If a company prefers their code to be closed and that they maintain it themselves, that's their choice. The government should however require that they receive a source license to all code they use.
Hello,
I did not see any mention of a bug bounty program. Is there one? If the federal government would like to not just have its open sourced software reviewed but actually receive reports of bugs, they should consider adding a bug bounty program to encourage programmers to report any errors they find to the federal government, instead of selling it to an adversary.
Regards,
Aryeh Goretsky
Dexter is a good dog.
At the _minimum_ a source code escrow service, so if a contract is left unfinished or a business files for bankruptcy, the work made can be picked up by others and things continued. If I were paying someone megabucks to write up something, either the source code will be part of the contract, or it will be escrowed so that one party doesn't have a monopoly.
Has 'open source' been redefined to mean nothing more than custom government software being shared with other branches of the same federal government?
He went open source, like all the villians!
It's also a myth that closed source is truly closed, the source code is out there somewhere and malicious parties certainly have the source for various closed source software.
The difference is that when the only way to obtain the source is illegal, legitimate whitehat researchers won't be able to look at it which gives the upper hand to those who don't care about legality. With open source, everyone has equal access.
It's also not really true that closed source has more attackers... Most networks place devices running open source code in front of devices running closed source to protect them (eg most firewalls and other security appliances are linux or bsd based), and there are many systems out there running on open source which would be highly sought after by various blackhats (eg the fastest supercomputers in the world run linux). There are plenty of people attacking open source code, and plenty of motivation for them to do so.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Wether code is open or closed has no relevance on the decision of the original authors to continue supporting it, the two things are not directly related at all.
Many closed source projects also cease being maintained, you just don't see the code languishing on github because its languishing on an internal code repository at the original vendor instead.
Some vendors decide to open source code that they no longer have any interest in, but the fact they're open sourcing it is not the reason they've lost interest in it - that's usually already happened or would have happened anyway. Open sourcing in this instance is just the equivalent of leaving goods on the curb with a "free to a good home" sign.
If closed source code is unmaintained the code is dead... If you use or depend on that code you're screwed.
If open source code is unmaintained the opportunity exists for someone else to take over maintenance. If the code still has users, those users can take over maintenance themselves or band together to do so. If noone is using the code then it doesn't really matter and it remains online as an educational reference which may still help someone in the future.
Being open presents additional opportunities which being closed does not, and being closed does not prevent code from ending up abandoned and unmaintained.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Unless I'm missing something there, but this just requires that code developed for one agency should be available to other agencies. Not that it should be 'open'.
This just sounds like 'we wanna get past licence agreements and not have to pay for it', not 'we want to make our code open'.
This guy clearly doesn't understand how cut-throat and back-stabbing federal contracting is. People will throw you under the bus in a heartbeat if it means they can weasel their way to a contract ahead of you. Hardware is easy to duplicate/copy, software is not. By forcing private industry to give up their intellectual property rights opens the door to well-connected contractors stealing from the little guy.
Not so. It's true that the policy focuses more on sharing within the federal government, but it also specifically requires that at least 20% of the code be shared with the public as OSS. It's a start.
- David A. Wheeler (see my Secure Programming HOWTO)
I don't think that "open source software" has been significantly redefined. Here's the definition of Open Source Software in this memo: "Software that can be accessed, used, modified, and shared by anyone. OSS is often distributed under licenses that comply with the definition of "Open Source" provided by the Open Source Initiative (https://opensource.org/osd) and/or that meet the definition of "Free Software" provided by the Free Software Foundation (https://www.gnu.org/philosophy/free-sw.html)." That's a little laxer than I'd prefer, but it seems reasonable enough.
- David A. Wheeler (see my Secure Programming HOWTO)
Open source does not mean that it has to be community developed. It means that the customer (the part of the government paying for it) must receive a bunch of rights along with the source code, including the rights to modify and distribute the code. On the same front page as this is a story about the Metropolitan Police having 27,000 computers still running Windows XP, which has known remotely exploitable vulnerabilities. The biggest reason for companies sticking with old versions of Windows is that they have some bit of software that doesn't work with Windows 7 and doesn't have updates. If a branch of the government has some open source software that doesn't work with their new OS, then it's 'just' a matter of cost to fix. They won't have problems where the original supplier has gone out of business, or isn't interested in producing a new version, or wants to sell you a different and incompatible product. They can always pay someone to port the code to the new OS, and then decide whether it's cheaper to do that than to migrate to a different system.
I am TheRaven on Soylent News
I assume this is what code.gov will be for.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
http://www.schlockmercenary.co...