[conartist6]

Huh? The DoD would not have used the package if they hadn't read every line, locked it down for updates, and were ready to patch it themselves if needed. Can you really imagine in a war they'd be like "damn, if only there were a second person we also don't trust at all to do this work for us cause otherwise we'd just be SOL"

[jandrewrogers]

It mostly doesn't work like that even for closed source in DoD. They have to weigh the risk against the very high cost of mitigating the risk. Their resources are large but not infinite.

Even if they trust the developer they may not trust their process. There are many cases of trusted developers having their development environments compromised such that bad actors were able to insert modifications into source trees, in commits signed by the developer. Most code is not developed in anything remotely resembling a high security context.

[moron4hire]

I don't know where you're working, maybe you work in some secret lab where everything is air-gapped and not even the pigeons are allowed within a mile of the facility. In which case, what the hell are you doing commenting on a public message board?

That is absolutely not how DoD works. The vast majority of code is contracted out. Nobody from DoD side is reading any of the code. It's all a series of affidavits and audits for configuration management process. Vendors assert everything's cool. Failed audits lead to fines or revocation of access. And the audits check up on documentation and config. They don't dig into code.

At no point in time is anyone, anywhere, in this process reading every single line of code. Not even A single line of code. I doubt they even read the Software Bill of Materials we're supposed to generate, because I've never heard any feedback on any of it.

[conartist6]

Doesn't change the fact that they can just fork it if it ever matters though...

[munificent]

By the time you know it matters, it's too late. And if it's not too late, you don't have enough data to know which of the thousands of packages you depend on should be forked and which shouldn't.

[kube-system]

You're missing the point of a supply chain risk assessment. Yes, you can fork a project to maintain it yourself. But, for an organization to do this, they need to allocate resources, e.g. time and money. This is part of the risk you are assessing for in a supply chain risk assessment.

[conartist6]

The risk quintuples with no lock files. And the number of maintainers is often not as important as the number of other users who are also putting eyes on the code

[nradov]

Just forking the code doesn't get you very far. Few of those products have what we would call reproducible builds so good luck trying to create a working release image if you don't have access to the contractor's infrastructure and tooling.

[seangrogg]

Damn, what country is this in? Maybe the US could learn a thing or two from this level of attention to detail.

[conartist6]

I'm only really describing the due diligence I do to keep people safe who might rely on my OSS work. I didn't realize I was so far ahead of the defense industry...

[tracker1]

I think you're seriously overestimating the amount of work the DoD will use... It really depends on what you are working on and where it will be used. I've worked on govt adjacent, military and banking projects... The most locked down in terms of packages I can use have been banks. In one case, a lawyer had to review (mostly licensing) every package that got added in to the local npm mirror for allowed internal use.. and another review for every version bump. Then of course, the (one) guy retires and there's no reviews for a month (so much for the launch date).

I've also been in a sealed environment, where I literally had to hand copy jQuery from an internet connected computer on one side of the room to an internal dev computer on the other side of the room... no disks, usb drives, etc allowed. That was a few days of "fun."

[kazinator]

> DoD would not have used the package if ...

That's a lot of faith in military intelligence.

[worik]

> military intelligence.

...is an oxymoron