Secure All Software - Issue #13 - Signal vs Noise a tale on Supply Chains

Supply Chain Scanning - Signal vs Noise

Recently was setting up basic SAST (Static Application Security Testing) and SCA (Software Composition Analysis) in one of my clients environments. I haven't done this from scratch in a while and was blown away by the amount of noise and false positives generated. We ended up with hundreds of findings that needed to be triaged, researched and followed up.

Why was there so much noise, what happened?

Usually I follow a systematic approach, but this time I just went in and enabled everything unfiltered. It can be overwhelming, frustrating and for some a scary experience.

Here is my usual approach:

First I would enable a SCA tool set it up to report CRITICAL findings first. The detected vulnerable dependencies then can be either updated right away if possible. When something takes more work I will create a backlog item and add it to a temporary acceptance list.

Sometimes there is no fix available or the dependency is not used (for example introduced in some transitive dependency but not used), it then ends up on the ignore list with a remark what is going on. Once all critical items are addressed the tool will be enabled to break the build on new findings.

With this we achieved the first milestone of having to address new critical vulnerabilities as soon as they appear.

Second run the SCA tool with HIGH and CRITICAL findings enabled and proceed in the same way. Then I take care of the MEDIUM and LOW findings.

Usually I wait a week between the individual levels. With this the teams can get used to the new tool and workflow and take ownership of the new findings without being overwhelmed.

For SAST I follow a similar approach. Depending on the tool, I am ignoring complete rule-sets from the beginning on. They have been of no value and generate the majority of noise.

More to this in the next edition.

How are you handling Supply Chain Scanning? Let me know andy@occamslabs.com

Links

Things I have been reading reading and things I find useful.

It’s a security framework, a check-list of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in your projects, businesses or enterprises. It’s how you get from safe enough to being as resilient as possible, at any link in the chain.

A collection of awesome security hardening guides, tools and other resources - GitHub - decalage2/awesome-security-hardening: A collection of awesome security hardening guides, tools and other resources

List of open source tools for AWS security: defensive, offensive, auditing, DFIR, etc. - GitHub - toniblyx/my-arsenal-of-aws-security-tools: List of open source tools for AWS security: defensive, offensive, auditing, DFIR, etc.

What is up?

We have no evidence that this incident involved any access to customer data or encrypted password vaults. Our products and services are operating normally.

Thank you

If you found this newsletter useful please forward it to someone who might also get value out of it. Let me know if you found something interesting to share, or have some feedback for the next issue at andy@occamslabs.com.

Have a fantastic day,

Andy