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.
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.
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.
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.
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.
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.
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.
Those are signals, which may be part of security, but far from adequate if you're talking about operational security, security of health records, security of network-wide root keys, etc.
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?
Additionally it explicitly encourages both government employees and contractors to contribute back to opensource project as part of their official duties.
> 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
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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?
No, you cannot license software as free or open source software while discriminating against a particular organization or field of use. You can write your own such license, but it will fail to meet criteria like the Open Source Definition, the Free Software Definition, and the Debian Free Software Guidelines.
Also, the DoD in particular has sovereign immunity, so if they infringe your copyright, you somehow find out about it, and you sue them for it in the US, they can just refuse the lawsuit. The best you could do in that case is something like a WTO lawsuit, which, well, I don't think you can get by with less than a million dollars in legal fees. You could sue somebody like Boeing or Lockheed Martin but you're still going to have one hell of an uphill battle there. However, those organizations would probably prefer not to spend tens of thousands of dollars to fight your lawsuit, so they may comply with the license even if they would probably win in court.
> Also, the DoD in particular has sovereign immunity,
The federal government has waived its sovereign immunity via statute for specific kinds of lawsuits, including for copyright infringement via 28 U.S.C. 1498(b).
There is also a school of thought that says that copyright infringement violates the Fifth Amendment's takings clause, but that has yet to be endorsed (or rejected) convincingly at a federal level.
> The best you could do in that case is something like a WTO lawsuit
There are WTO disputes, but these can only be brought by one WTO member (e.g., a sovereign government) against another and generally the outcome of WTO disputes does not involve compensation.
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.
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.
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.
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.
The DoD is huge. It's larger than most US states. Would you exclude Cerner's healthcare records systems? Fuji? Agfa? Would you exclude the Veteran's Administration hospitals? Would you exclude the agencies responsible for safe water, forestry, and sewage treatment plants on bases? Where, exactly, would you draw that line, and how would you ensure DoD is able to replicate your logic so as to end at the conclusions you expect?
It's your code. You own the rights to it. You can say exactly who uses it if you like.
You can add a clause to the licence saying "the following people/organisations are specifically prohibited from using this code: US DoD, etc" - you may want to word this better to prevent loopholes, but that's the gist of it.
As detaro and kragen have pointed out, any software licence which prohibits military use is by definition neither a Free Software licence (under the FSF definition) [0] nor an Open Source licence (under the OSI definition). [1]
Sounds pretty reasonable.