4 ms·

>They look at things like NPM and Maven and just see unlimited attack vectors from people who have no idea about security, and they aren’t wrong. Then what do

>They look at things like NPM and Maven and just see unlimited attack vectors from people who have no idea about security, and they aren’t wrong. Then what do they do? Aren't there tools to check for security vulnerabilities in the market like Sonar Qube? Wouldn't (or couldn't) the millitary run a beefed up version of that and developers can't check in code without ensuring 100% compliance to security vulnerabilities

NegativeK 2y ago
I'm not sure what the military does, but automated scanners will never be a panacea. And I encourage open source devs who get security compliance demands without patches or significant collaboration to ban the person filing the issue.
- teitoklien 2y ago
  Haha, very true. It is insane how demanding and toxic some “developers” can be towards opensource creators and maintainers, as if they own them. But on the other hand, open source or giving things out for free for people to try out and use is also a great way to find interesting friends who just want to build cool stuff together, and make new friends along the way :D That part is prolly the only reason why I like opensource so much, it attracts certain kinds of interesting people depending on the project you’re working on.
linuxftw 2y ago
Lots of audit and compliance tooling exists. What happens is they turn on a new datacenter, get 150k vulnerabilities, and then try to address them one by one. There's a lot of dead weight and incompetence in government IT.
cess11 2y ago
Look at JVM exploits from the last years. They're usually chains of quite clever hops, for example from a serialisation or deserialisation vulnerability. Sonar is not going to help you with that and when something like it pops up it might already have been used 'in the wild' for some time, and then you have the problem of rolling out patches into the field. You'd be better off going back to Ada.
- sk5t 2y ago
  > JVM exploits from the last years Entirely user/library serialization or fine cryptographic issues, and not the VM, no?
  - cess11 2y ago
    How the VM and its bytecode works is usually a part of the chain.
austin-cheney 2y ago
They use approved software lists containing a list of software that is already approved, by vendor version number, for use within your organization. There are teams that analyze popular commercial software for approved usage, often including source code inspection. Bank of America does the same thing.
jandrewrogers 2y ago
Tools like Sonar Qube are pretty shallow. Anecdotally, a robust development process will produce software that always reads clean on those scanners even if those scanners are not part of your development process. They detect defective development processes more than they detect defective code or designs. Parts of the US DoD do have more rigorous testing that is considerably broader in scope than commercial linters and such, and evaluates for threats that commercial systems don't consider. Many of these tests reliably break open source software. It is unclear how thorough or exhaustive these audits or tests are -- it can be quite opaque. For good or bad, having been through several serious security audits by multiple organizations, my software always came back clean so it is difficult to calibrate their sensitivity from the outside.

NegativeK 2y ago

I'm not sure what the military does, but automated scanners will never be a panacea. And I encourage open source devs who get security compliance demands without patches or significant collaboration to ban the person filing the issue.

teitoklien 2y ago
Haha, very true. It is insane how demanding and toxic some “developers” can be towards opensource creators and maintainers, as if they own them. But on the other hand, open source or giving things out for free for people to try out and use is also a great way to find interesting friends who just want to build cool stuff together, and make new friends along the way :D That part is prolly the only reason why I like opensource so much, it attracts certain kinds of interesting people depending on the project you’re working on.

linuxftw 2y ago

Lots of audit and compliance tooling exists. What happens is they turn on a new datacenter, get 150k vulnerabilities, and then try to address them one by one. There's a lot of dead weight and incompetence in government IT.

cess11 2y ago

Look at JVM exploits from the last years. They're usually chains of quite clever hops, for example from a serialisation or deserialisation vulnerability. Sonar is not going to help you with that and when something like it pops up it might already have been used 'in the wild' for some time, and then you have the problem of rolling out patches into the field. You'd be better off going back to Ada.

sk5t 2y ago
> JVM exploits from the last years Entirely user/library serialization or fine cryptographic issues, and not the VM, no?
- cess11 2y ago
  How the VM and its bytecode works is usually a part of the chain.

austin-cheney 2y ago

They use approved software lists containing a list of software that is already approved, by vendor version number, for use within your organization. There are teams that analyze popular commercial software for approved usage, often including source code inspection. Bank of America does the same thing.

jandrewrogers 2y ago

Tools like Sonar Qube are pretty shallow. Anecdotally, a robust development process will produce software that always reads clean on those scanners even if those scanners are not part of your development process. They detect defective development processes more than they detect defective code or designs. Parts of the US DoD do have more rigorous testing that is considerably broader in scope than commercial linters and such, and evaluates for threats that commercial systems don't consider. Many of these tests reliably break open source software. It is unclear how thorough or exhaustive these audits or tests are -- it can be quite opaque. For good or bad, having been through several serious security audits by multiple organizations, my software always came back clean so it is difficult to calibrate their sensitivity from the outside.