- [CramHacks] Newsletter #13: Flaws in Open-Source Vulnerability Disclosures
[CramHacks] Newsletter #13: Flaws in Open-Source Vulnerability Disclosures
CramHacks Chronicles: Key Insights On Software Supply Chain Risks
🥳 Happy Monday! 🥳
I’m graduating with my MS in Computer Science 🥳 🥳 🥳
Software Supply Chain Security
Kyle Kelly 👀, Semgrep Security Researcher, delves into how practitioners can efficiently manage dependency versions by utilizing manifest files, lockfiles, and SemVer specifications.
👋 Please follow SemVer specifications ☹️.
👋 This was funny to read after publishing my Semgrep blog post on Efficient Dependency Management. It is very similar to my article, but focused on containers! Check it out to see why and how you must keep those images up-to-date.
👋 when cURL recently announced they’d be announcing a vulnerability, I think most of Twitter was talking about how they found the patch and began reversing it before it was officially revealed.
But this article is an absolute banger. I love everything about it - it highlights a fundamental issue likely being leveraged by malicious actors: no secret sauce here, just a blatant gap in the workflow.
“These provide insight into the Community, Strategy, Governance, and Compliance/Security of open source projects.”
👋 My first reaction was… “Oh great, another model,” but I kinda like this one. All I know about it is what this post mentions, but using a model to determine an OSS project’s viability seems like a good idea.
Aqua’s Yakir Kadkoda and Assaf Morag summarize recent research that uncovered over 90 valid credentials, providing access to their respective registries. These credentials were disclosed from base64 encoded configurations. Encoded does not mean secure!
includes three security fixes:
net/http: limit chunked data overhead
cmd/go: go get may unexpectedly fallback to insecure git
path/filepath: retain trailing \ when cleaning paths like \\?\c:\
Only one percent of the generated SBOMs contain the “NTIA minimum elements” data for all reported components.
Most SBOMs across most SBOM generation tools contain rich, if incomplete, metadata.
A detailed analysis of two of the SBOM generation tools on the same set of artifacts finds that the number of reported components differs by more than 10 in over 16% of the sample, suggesting that simply viewing an SBOM, at least currently, is not enough to know the SBOM’s quality.
👋 Reviewing SBOMs on a now weekly basis (really seems like daily), I can attest to this. I’ve previously shared OWASP’s new benchmark for SBOM quality and sbombenchmark.dev, but there’s still a lot of work to do.
Some self-evident but also obviously not followed principles for secure software development.
👋 This isn’t revolutionary but is probably a necessary evil to have, just to say these are documented. One thing I would’ve probably included is updating the status of a project; for example, actively maintained versus deprecated. After 24 hours of creation, most projects are considered “dead” and are never touched again. Unmaintained dependencies are everywhere.
“In late 2023, the NVD will retire its data feeds while working to guide any legacy users to updated application-programming interfaces (APIs).”
Until Next Time! 👋
Hey, you made it to the bottom – thanks for sticking around!
Questions, ideas, or want to chat? Slide into my inbox! 💌
Don't hesitate to forward if someone could benefit from this.
See you next Monday!