Wolf480pl
@domi @lanodan
IME the hardest part of the problem is that if a python library has 50 functions
one of them is vulnerable
and you use a different one
with input that is not user-controlled
it's still getting flagged, and there's no way to filter that out without someone who understands the code taking a look at it.
In an ideal world, vulns would be expressed through a type system.
1/
Wolf480pl
@makdaam @domi @lanodan
don't worry about thread necromancy, it hasn't even been a week yet
So you're saying that the checkbox exists purely for performative/blameshifting purposes?
I think even if that is true, the side effect of complying with the checkbox is doing some good things. In this case - how do you make the CVE scanner happy without patching at least some vulns?
And if you patch some vulns, you're already doing better than those who don't give a fuck.
1/
Leszek
@wolf480pl @domi @lanodan Sorry for thread necromancy, but I think this is the core of the good/bad distinction.
Your goal is to fix any security issues. For most large companies the goal is not to be liable for security issues in their product/service (usually through standards compliance). Those are two different goals that can be in direct conflict.
CVEs enable a quick scan to improve security, but also they give people a way to do the performative CVE Scan to check a compliance box.
Wolf480pl
@domi @lanodan
but IRL, if I could just
take all known exploits
automatically run them against our public endpoints, to find all the things a script kiddie can easily find
and patch only those things
that'd probably prevent 80% of the likely attacks for 10% of the effort
Wolf480pl
@makdaam @domi @lanodan
Now, you could argue that if the checkbox didn't shield companies from liability, they would care more about security, because simply ignoring vulns would get them sued to oblivion.
And maybe that is the case in some fields.
But IME it's more about the choice between trying to meet an impossible standard, and not giving a fuck thus doing nothing.
2/2
Wolf480pl
@makdaam @domi @lanodan
oh, and also about goals
At my $dayjob, the reason I do anything about vulns at all is compliance with a standard.
But I look at the standard, try to figure out why someone would put a particular requirement in the standard, and try to think of something that we could do that is actually useful, that could also be argued to check the box.
I think this might be a rare attitude.
Leszek
@wolf480pl @domi @lanodan The answer, as always, is "it depends".
Basically it depends on the people implementing compliance. If they care, compliance and security are aligned. You can use most compliance tools to make life of your SoC easier. Like you wrote before - you can decide on dev teams' priorities, you can learn about practices in other places etc.
But also you can do the absolute minimum to pass an audit and fight with people who discover actual issues outside the approved process.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.