Interesting, no mention of any requirements towards software manufacturers themselves.
If you think about it, this will further incentivize poor-quality software as responsibility of vulnerability response is now being laid on the product owner.
Interesting, no mention of any requirements towards software manufacturers themselves.
If you think about it, this will further incentivize poor-quality software as responsibility of vulnerability response is now being laid on the product owner.
I would suggest people look at a very foundational essay on this [2]. Key quote: "Security is a process, not a product. Products provide some protection, but the only way to effectively do business in an insecure world is to put processes in place that recognize the inherent insecurity in the products. "
How many times do we have to learn this?
[1] In quotes 'cause "secure software" does not exist. In two different ways; software always has bugs and using a piece of software incorrectly makes a secure system insecure.
[2] https://www.schneier.com/essays/archives/2000/04/the_process...
Firstly there's the information asymmetry for non-technical users - they don't think of themselves as buying security, they think of themselves as buying a remote access solution. They therefore don't see this as a process, but instead as a product or solution. That means they're surprised and caught unaware when something goes wrong.
The second issue is that people creating the software aren't themselves thinking about security, because the customer isn't buying security, or comparing security. And how do you measure or quantify or observe security? There's no commercial incentive to invest a month in hardening a product against attack, unless that month of engineering effort sees more sales and revenues. And since the people who buy are satisfied by slideware and specification sheets for security, nothing changes.
I think we need a whole change to how we buy software, hardware, and solutions in general, to see this change. The underlying economics don't incentivise secure products, in fact they actively discourage them.
Perfectly secure software does not exist. More secure and less secure software certainly does exist.
Which is why software should be expected to provide some basic level of protection.
In any org there will be a proportion of idiots who cannot be trusted to do the right thing, and software should be designed to minimise the damage their idiocy can generate.
This isn't enough to make an org secure, but it's a good start on whack-a-mole with the most obvious attack vectors.
The real problem is that too much of the industry - both management and devs - lacks maturity and professionalism. There's too much casual hobby tinkering, too much "But that's too expensive", and too much "Get it out the door and worry about it later".
There isn't enough conscientious attention to detail and far, far too little understanding of the disastrous - literally potentially explosive - consequences of serious security failures.
And CS courses teach far too little of all of the above. Academic algo noodling is one thing. But the reality is that computers can literally be as dangerous as weapons - and should be treated as such.
In some sense security is binary - if your software happens to have even a single mistake that results in RCE or authentication failure, then it's totally exploitable and does not provide any level of protection whatsoever. And as experience shows, we seem unable to write any software without such mistakes, even if we try really, really hard by skilled people with security in mind, as far as I recall every popular piece of software that needed to be secure has had vulnerabilities.
This isn't saying you're wrong that quality can raise the bar. It's saying that time and context also lower the bar. Especially, not being subject to "that’s in easy reach of anyone who can program" not guarantee by any purely default action - notably not guaranteed by spending X dollars.
Obviously it's difficult to draw the line, and that's why we have courts. The company will argue that they did all that was possible, but as sometimes happens, something got through; the plaintiff will argue that the company's software had serious flaws because they were negligent or cut corners or had poor development processes or whatever. However imperfect the process is, the court can render judgment case-by-case.
(Before someone suggests this, I'm not trying to say that a random open source developer who works on OpenSSL should be held liable here. But if you're selling a product, you should hold some liability for when that product fails.)
Imposing this requirement on their own agencies is enforceable because there's software that can generate an SBOM, at least from container images.
Then the agencies will have to choose software that meets compliance requirements, so they're the ones putting pressure on their chosen vendors. It follows logically that a vendor who wants a better chance of being chosen for more government contracts will make it easy to obtain SBOMs for their software.
Speaking from US Gov perspective - if the company is part of a contract (and ~40% of the Gov are contractors), Gov certainly can.
They can put nearly anything (legal) into the RFP/Q. Even if they do not say "give us your BoM", they can wrap it in requirements that in essence delivers the same exact result.
That said, it is Gov mistake to ask for the BoM. They will do little with it in a timely fashion, and lack the expertise to identify risks, and lack the resources to go after it. The best contracts are the ones where the rules and parameters are set for the contractor, (i.e. no untested software, no foreign influence, no this, no that, must have this and that), and auditing of the compliance.
I've never even heard of the software the government is using. Why aren't they using Cisco AnyConnect like literally every other company I've worked for who has a VPN?
Even if you report it, this kind of behavior is so normal, I'd be shocked if it does anything other than create more billable project management hours for the company you are protesting.
Not really, this is more about transparency of all components and letting people downstream be aware that there is an issue and either fix it, mitigate it, or raise the issue upstream. My guess is that this is related to Allan Friedman's SBOM work at NTIA (sorry - this is not the most up to date link: https://www.csiac.org/podcast/software-bill-of-materials-sbo... )
The problem that keeps on getting hit time and time again is that both end users and product manufacturers do not know everything that is in their system. Consider the case of say, an MRI machine. What OS is it running and how up to date is it? If the end user has an SBOM they can better evaluate that and demand fixes if there are known issues. Likewise if the MRI manufacturer is good at making MRIs, but not so much at knowing if their version of Windows on the MRI is out of date, the SBOM for the MRI can be analyzed to automatically flag problems.
You can regulate all you want about "There must be no open issues" and plenty of certifications for the Fed government do have that language. The problem this answers is forcing a listing of every component so that "Sorry I didn't know OpenSSH v.1.2.3 is out of date" or "I had no idea we were running Windows 95 on this hardware" are no longer valid excuses.