7 ms·

Guidance on Software Development and Open Source Software [pdf]

119 points by killjoywashere 5y ago

VWWHFSfQ 5y ago
So basically, use open-source software as much as you can. But rigorously verify the quality and security when it's used in DoD systems. Sounds pretty reasonable.
- ford 5y ago
  Google does something similar and really this is sensible for any organization of sufficient size. When I was there (I believe) they had a security team review any new third party library, and once reviewed they would copy the entire source code into their monorepo. Fortunately Google is large enough that having a net-new dependency was quite rare.
  - froh 5y ago
    That's also what the large and maintained Linux distro s do: do an in depth review of any security critical patches, put a security aware maintainer on the package and maintain an authenticated copy of the source code.
    - kragen 5y ago
      Commonly they accept patches from upstream without reviewing them. If Artifex were to slip malware into the next version of GhostScript or Google were to slip malware into the next version of Chrome, probably nobody at Debian would notice.
      - froh 5y ago
        SLES and rhel don't simply add patches from mainline. For Ubuntu I hope it's the same. And even in the community distros you have maintainers. All professionally managed packages, kernel, libc, gcc/llvm postgres, python, etc etc have full time professional mainline maintainers. And package maintainers with a high working ethos as reviewers and gatekeepers. The problem is with leaf packages in ginornous self serviced blindly trusting huge repos like pip or cargo or younameit, npm, with huge numbers of tiny packages with no tangible responsibility whatsoever.
        kragen 5y ago
        Hmm, are you saying Red Hat has someone who reviews every line of code Google adds to Chromium and every line of code Apple adds to LLVM? And who will refuse patches they aren't confident in? That's not impossible but it definitely isn't my understanding of how Red Hat works.
- divbzero 5y ago
  The “rigorously verify the quality and security” is the hard part easier said than done for any reasonably complex software. That challenge exists of course whether the software is open-source or closed-source.
  - d4mi3n 5y ago
    Ah, our old friend supply chain security. This is a very, very hard problem to solve without some serious coordination and effort. To do this well you need to do all kinds of things like: 1. Verifying the authenticity of the software you're looking at. Is that really libxml or has someone fed you a poisoned package? Does it have a checksum? Is the registry or repository we pulled it from adequately secured? 2. Verifying the provenance of a particular version of a package. Who made this change? Why did they make it? Is the change safe? 3. Vetting the governance of a package or library. We may know of Apache and have some confidence in the governance of that project, but what about leftpad of NodeJS/npm fame? Is that logging library we got for our Rust app off of crates.io managed by a reputable OSS developer and/or company, or are the motivations of the entities building it uncertain? Can they be bought? Bought out? Sued? Blackmailed? If you're looking at this with the mindset of a state-sponsored organization that handles anything remotely important these are not unreasonable considerations. The list goes on and on. It helps if you're working in an ecosystem that has high level of quality standards for the libraries or software packages that are being used, but there's always more to dig up the deeper you go into a dependency tree. I'm of the opinion that supply chain attacks can be mitigated, but never eliminated. Having many eyes on a project helps (thanks to all of you working on projects with openly available sources!). We're still a long way from making our industry's tools and development processes naturally robust to these things, though I'm excited to see more dialog around these issues.
    - Sythe_nl 5y ago
      I would say it is solved by using the number of downloads, issues and people involved as a guide.
      - killjoywashere 5y ago
- TrueDuality 5y ago
  Additionally it explicitly encourages both government employees and contractors to contribute back to opensource project as part of their official duties.
- 0x445442 5y ago
  It does sound reasonable but will they invest in the resources to make this easier to those in the trenches. For example, I'm wondering why any DoD software would have the need to reach outside it's own internal repositories for it's dependencies. Repositories that have the adequate resources allocated to vet it's offerings for security vulnerabilities etc. Or are they going to make every Program Manager responsible for assuring their devs aren't reaching out to NPM or Maven Central?
octagons 5y ago
https://archive.is/F5EUj https://archive.is/F5EUj
- tzs 5y ago
  I'm curious what the point of that link is? Usually people post such links either to get around paywalls or because there are problems with the original site such as overload or the site have something on it obnoxious that the archiver doesn't copy. No paywall in this case that I can see, nor overload, nor anything obnoxious. Heck, the site doesn't even set any cookies.
  - octagons 5y ago
    Some might feel apprehensive about visiting US government websites. I have been in this position before, so I often think like that. I figured I’d offer an easy to find alternative source.
  - Melatonic 5y ago
    Of course Octagon would not want you visiting the damn inferior Pentagon!
    - octagons 5y ago
      I’m just looking out for my fellow geometry nerds.
  - Terry_Roll 5y ago
    Maybe they dont want to hit an, obviously, US military server like https://dodcio.defense.gov https://dodcio.defense.gov perhaps?
  - passer_byer 5y ago
    In my case, extremely useful as Google requested access to my location, and I declined. With this link, I get to read it with a tiny bit of anonymity. But, I do kid myself. Google already tracks me across multiple sites, so it becomes a small victory if I can find a way to deny them this one bit of data they would like to have.
supernova87a 5y ago
For such a key strategic policy document (which calls out for attention by people who are unfamiliar with the topic), you would wish that they could also communicate it through a simpler more eye-catching format (like an infographic, or banner / poster that someone could tape up on a cubicle wall) as emblematic of the initiative. (with links to more in-depth details for anyone who needs them) Despite its importance, this document has the format / look and feel of a procurement for bulk purchase of machine screws.
- newsclues 5y ago
  Memos are the primary armament of the pentagon. This is preferable to a PowerPoint.
- _djo_ 5y ago
  I would think it’s the other way around: Important policy documents like this should be written in this format in order to minimise ambiguity and provide the space for detail. As a formal guidance memorandum this format also allows for each section and paragraph to be uniquely referenced through with a logical structure, same as legal documents. There will almost certainly be infographics and posters made of this document’s key points and distributed around the DoD, but they’ll refer back to this as the canonical source. Honestly if more software companies worked this way there’d be less confusion and fewer cases of building the wrong thing, loss of institutional knowledge, and duplicated effort.
  - supernova87a 5y ago
    Well, I think I agree, I'm just saying that I hope that a more communication / publicity generating document accompanies this one.
- Animats 5y ago
  If you've had anything to do with DoD, in uniform or out, you've seen stuff like that. Now, DoD often does provide info in much more informal formats.[1] For this issue, there is a FAQ.[2] It covers not only common misconceptions but such things as how Eben Moglen enforces the GPL and the difference between the 2-clause and 3-clause BSD licenses. There is a DoD forum on Google Groups about this.[3] The proponent of that document is active on that forum. [1] https://www.psmagazine.army.mil/ https://www.psmagazine.army.mil/ [2] https://dodcio.defense.gov/Open-Source-Software-FAQ/ https://dodcio.defense.gov/Open-Source-Software-FAQ/ [3] https://groups.google.com/g/mil-oss https://groups.google.com/g/mil-oss
PaulDavisThe1st 5y ago
Direct link to the FAQ mentioned on page 1, in most ways much more interesting than the memo: https://dodcio.defense.gov/Open-Source-Software-FAQ/ https://dodcio.defense.gov/Open-Source-Software-FAQ/
jpthurman 5y ago
That DoD is willing to address the need to leverage OSS and set a policy that balances and mitigates risk-benefit is a really positive step. I left the military almost 4yrs ago and even at the most advanced organizations there was a huge under-appreciation for the need to invest in software capabilities across the board. I’m glad to see this.
rawland 5y ago
This makes total sense for any organization. I like the memo instead of usual slides. I wonder if they contribute back by fixing issues or rather fix them for themselves and try to 'use' them otherwise when found.
woile 5y ago
> For example, "is the OSS project active and/or stable," "when was the last time this OSS project was updated," and "who is contributing to this OSS." Risk mitigations might include consideration of commercial or in-house support for the OSS component, or availability of feasible alternatives (MOSA) if the component should need replacement in the future Does MOSA includes donations to the mainteners?
boffinAudio 5y ago
What is the counter-balance to this memo? How do F/OSS developers ensure their work never ends up being used by the DoD for any purpose whatsoever? As a F/OSS developer I am ideologically opposed to my work ever being used by the US' DoD or any of its organizations. Has anyone successfully built F/OSS products with a license that disallows use by military organizations, and if so - what is involved in maintaining that situation?
- detaro 5y ago
  There's a few licenses like that, but I'm not aware of a major project using them and they also don't get recognized as Open-Source licenses, due to the criteria for those banning restrictions on specific use cases.
  - boffinAudio 5y ago
    After some research I've come to the conclusion that the License can't have such restrictions and still be considered 'free', but a "Terms of Use" clause elsewhere in the code can be used to restrict how programs built from the free code can be used. Quite an interesting conundrum, this - but I suppose one that is simply the state of things: if you want your stuff to be free and open, you cannot release it to the world and expect/demand that it will not be weaponized, as is the case with any and all technology. Sobering.
    - kragen 5y ago
      No, that is not correct. If a clause is limiting how programs built from the free code can be copied (or sold, imported, publicly performed, etc., the various exclusive rights granted under copyright, which do not include "used") then that clause is part of the license. It is perfectly legal for a license to discriminate against a field of use such as weaponization, in which case it fails to be free software or open source software.
      - boffinAudio 5y ago
        Right, thanks for the clarification and it does in fact make sense. Sobering times for those of us who don't want our F/OSS products used by the war machine.
throw10920 5y ago
> The Department must follow an "Adopt, Buy, Create" approach to software, preferentially adopting existing government or OSS solutions before buying proprietary offerings, and only creating new non-commercial software when no off-the-shelf solutions are adequate. This explains why software sucks so much in some places (e.g. payroll) there - because when the only software available is bad proprietary software (you only get good software for some specific fields, like email, but bad software exists for every conceivable need), the DoD prefers to spend extravagant amounts of taxpayer money on purchasing that existing solution over developing their own.

So basically, use open-source software as much as you can. But rigorously verify the quality and security when it's used in DoD systems. Sounds pretty reasonable.

ford 5y ago
Google does something similar and really this is sensible for any organization of sufficient size. When I was there (I believe) they had a security team review any new third party library, and once reviewed they would copy the entire source code into their monorepo. Fortunately Google is large enough that having a net-new dependency was quite rare.
- froh 5y ago
  That's also what the large and maintained Linux distro s do: do an in depth review of any security critical patches, put a security aware maintainer on the package and maintain an authenticated copy of the source code.
  - kragen 5y ago
    Commonly they accept patches from upstream without reviewing them. If Artifex were to slip malware into the next version of GhostScript or Google were to slip malware into the next version of Chrome, probably nobody at Debian would notice.
    - froh 5y ago
      SLES and rhel don't simply add patches from mainline. For Ubuntu I hope it's the same. And even in the community distros you have maintainers. All professionally managed packages, kernel, libc, gcc/llvm postgres, python, etc etc have full time professional mainline maintainers. And package maintainers with a high working ethos as reviewers and gatekeepers. The problem is with leaf packages in ginornous self serviced blindly trusting huge repos like pip or cargo or younameit, npm, with huge numbers of tiny packages with no tangible responsibility whatsoever.
      - kragen 5y ago
        Hmm, are you saying Red Hat has someone who reviews every line of code Google adds to Chromium and every line of code Apple adds to LLVM? And who will refuse patches they aren't confident in? That's not impossible but it definitely isn't my understanding of how Red Hat works.
divbzero 5y ago
The “rigorously verify the quality and security” is the hard part easier said than done for any reasonably complex software. That challenge exists of course whether the software is open-source or closed-source.
- d4mi3n 5y ago
  Ah, our old friend supply chain security. This is a very, very hard problem to solve without some serious coordination and effort. To do this well you need to do all kinds of things like: 1. Verifying the authenticity of the software you're looking at. Is that really libxml or has someone fed you a poisoned package? Does it have a checksum? Is the registry or repository we pulled it from adequately secured? 2. Verifying the provenance of a particular version of a package. Who made this change? Why did they make it? Is the change safe? 3. Vetting the governance of a package or library. We may know of Apache and have some confidence in the governance of that project, but what about leftpad of NodeJS/npm fame? Is that logging library we got for our Rust app off of crates.io managed by a reputable OSS developer and/or company, or are the motivations of the entities building it uncertain? Can they be bought? Bought out? Sued? Blackmailed? If you're looking at this with the mindset of a state-sponsored organization that handles anything remotely important these are not unreasonable considerations. The list goes on and on. It helps if you're working in an ecosystem that has high level of quality standards for the libraries or software packages that are being used, but there's always more to dig up the deeper you go into a dependency tree. I'm of the opinion that supply chain attacks can be mitigated, but never eliminated. Having many eyes on a project helps (thanks to all of you working on projects with openly available sources!). We're still a long way from making our industry's tools and development processes naturally robust to these things, though I'm excited to see more dialog around these issues.
  - Sythe_nl 5y ago
    I would say it is solved by using the number of downloads, issues and people involved as a guide.
    - killjoywashere 5y ago
TrueDuality 5y ago
Additionally it explicitly encourages both government employees and contractors to contribute back to opensource project as part of their official duties.
0x445442 5y ago
It does sound reasonable but will they invest in the resources to make this easier to those in the trenches. For example, I'm wondering why any DoD software would have the need to reach outside it's own internal repositories for it's dependencies. Repositories that have the adequate resources allocated to vet it's offerings for security vulnerabilities etc. Or are they going to make every Program Manager responsible for assuring their devs aren't reaching out to NPM or Maven Central?

octagons 5y ago

https://archive.is/F5EUj https://archive.is/F5EUj

tzs 5y ago
I'm curious what the point of that link is? Usually people post such links either to get around paywalls or because there are problems with the original site such as overload or the site have something on it obnoxious that the archiver doesn't copy. No paywall in this case that I can see, nor overload, nor anything obnoxious. Heck, the site doesn't even set any cookies.
- octagons 5y ago
  Some might feel apprehensive about visiting US government websites. I have been in this position before, so I often think like that. I figured I’d offer an easy to find alternative source.
- Melatonic 5y ago
  Of course Octagon would not want you visiting the damn inferior Pentagon!
  - octagons 5y ago
    I’m just looking out for my fellow geometry nerds.
- Terry_Roll 5y ago
  Maybe they dont want to hit an, obviously, US military server like https://dodcio.defense.gov https://dodcio.defense.gov perhaps?
- passer_byer 5y ago
  In my case, extremely useful as Google requested access to my location, and I declined. With this link, I get to read it with a tiny bit of anonymity. But, I do kid myself. Google already tracks me across multiple sites, so it becomes a small victory if I can find a way to deny them this one bit of data they would like to have.

supernova87a 5y ago

For such a key strategic policy document (which calls out for attention by people who are unfamiliar with the topic), you would wish that they could also communicate it through a simpler more eye-catching format (like an infographic, or banner / poster that someone could tape up on a cubicle wall) as emblematic of the initiative. (with links to more in-depth details for anyone who needs them) Despite its importance, this document has the format / look and feel of a procurement for bulk purchase of machine screws.

newsclues 5y ago
Memos are the primary armament of the pentagon. This is preferable to a PowerPoint.
_djo_ 5y ago
I would think it’s the other way around: Important policy documents like this should be written in this format in order to minimise ambiguity and provide the space for detail. As a formal guidance memorandum this format also allows for each section and paragraph to be uniquely referenced through with a logical structure, same as legal documents. There will almost certainly be infographics and posters made of this document’s key points and distributed around the DoD, but they’ll refer back to this as the canonical source. Honestly if more software companies worked this way there’d be less confusion and fewer cases of building the wrong thing, loss of institutional knowledge, and duplicated effort.
- supernova87a 5y ago
  Well, I think I agree, I'm just saying that I hope that a more communication / publicity generating document accompanies this one.
Animats 5y ago
If you've had anything to do with DoD, in uniform or out, you've seen stuff like that. Now, DoD often does provide info in much more informal formats.[1] For this issue, there is a FAQ.[2] It covers not only common misconceptions but such things as how Eben Moglen enforces the GPL and the difference between the 2-clause and 3-clause BSD licenses. There is a DoD forum on Google Groups about this.[3] The proponent of that document is active on that forum. [1] https://www.psmagazine.army.mil/ https://www.psmagazine.army.mil/ [2] https://dodcio.defense.gov/Open-Source-Software-FAQ/ https://dodcio.defense.gov/Open-Source-Software-FAQ/ [3] https://groups.google.com/g/mil-oss https://groups.google.com/g/mil-oss

PaulDavisThe1st 5y ago

Direct link to the FAQ mentioned on page 1, in most ways much more interesting than the memo: https://dodcio.defense.gov/Open-Source-Software-FAQ/ https://dodcio.defense.gov/Open-Source-Software-FAQ/

jpthurman 5y ago

That DoD is willing to address the need to leverage OSS and set a policy that balances and mitigates risk-benefit is a really positive step. I left the military almost 4yrs ago and even at the most advanced organizations there was a huge under-appreciation for the need to invest in software capabilities across the board. I’m glad to see this.

rawland 5y ago

This makes total sense for any organization. I like the memo instead of usual slides. I wonder if they contribute back by fixing issues or rather fix them for themselves and try to 'use' them otherwise when found.

woile 5y ago

> For example, "is the OSS project active and/or stable," "when was the last time this OSS project was updated," and "who is contributing to this OSS." Risk mitigations might include consideration of commercial or in-house support for the OSS component, or availability of feasible alternatives (MOSA) if the component should need replacement in the future Does MOSA includes donations to the mainteners?

boffinAudio 5y ago

What is the counter-balance to this memo? How do F/OSS developers ensure their work never ends up being used by the DoD for any purpose whatsoever? As a F/OSS developer I am ideologically opposed to my work ever being used by the US' DoD or any of its organizations. Has anyone successfully built F/OSS products with a license that disallows use by military organizations, and if so - what is involved in maintaining that situation?

detaro 5y ago
There's a few licenses like that, but I'm not aware of a major project using them and they also don't get recognized as Open-Source licenses, due to the criteria for those banning restrictions on specific use cases.
- boffinAudio 5y ago
  After some research I've come to the conclusion that the License can't have such restrictions and still be considered 'free', but a "Terms of Use" clause elsewhere in the code can be used to restrict how programs built from the free code can be used. Quite an interesting conundrum, this - but I suppose one that is simply the state of things: if you want your stuff to be free and open, you cannot release it to the world and expect/demand that it will not be weaponized, as is the case with any and all technology. Sobering.
  - kragen 5y ago
    No, that is not correct. If a clause is limiting how programs built from the free code can be copied (or sold, imported, publicly performed, etc., the various exclusive rights granted under copyright, which do not include "used") then that clause is part of the license. It is perfectly legal for a license to discriminate against a field of use such as weaponization, in which case it fails to be free software or open source software.
    - boffinAudio 5y ago
      Right, thanks for the clarification and it does in fact make sense. Sobering times for those of us who don't want our F/OSS products used by the war machine.

throw10920 5y ago

> The Department must follow an "Adopt, Buy, Create" approach to software, preferentially adopting existing government or OSS solutions before buying proprietary offerings, and only creating new non-commercial software when no off-the-shelf solutions are adequate. This explains why software sucks so much in some places (e.g. payroll) there - because when the only software available is bad proprietary software (you only get good software for some specific fields, like email, but bad software exists for every conceivable need), the DoD prefers to spend extravagant amounts of taxpayer money on purchasing that existing solution over developing their own.