[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.