5 ms·

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 reasona

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?

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?