- [CramHacks] Newsletter #10: The !CVE Program is ...
[CramHacks] Newsletter #10: The !CVE Program is ...
CramHacks Chronicles: Key Insights On Software Supply Chain Risks
🥳 Happy Monday! 🥳
I couldn’t imagine it being Wednesday.
AI: Navigating the Emerging Threat Landscape for Community FIs
Software Supply Chain 101: Understanding Dependencies
Software Supply Chain Security
“The mission of the !CVE Program is to provide a common space for cybersecurity !vulnerabilities that are not acknowledged by vendors but still are serious security issues.”
👋 I really didn’t want to bring any more attention to this, but I feel the need to say something about it… it’s not a good idea, I’m sorry. By all means, name and shame vendors who fail to acknowledge vulnerabilities, but this is so extra.
Jeff Luszcz talks about why you might not want to hit the share button on your SBOM. These reasons include non-disclosure agreements with software vendors, revealing technologies to competitors, and, of course, may reveal some dirty laundry.
👋 Honestly, I’m still blown away that the industry is moving in the direction of publicizing / sharing SBOMs. The world is in for a shock when they see some data on these bad boys (i.e., average number of vulnerabilities, unmaintained dependencies). That said, very few people know what to even do with an SBOM when they’re given one, so we have some time 😅. Reachability, VEX, and the alike will hopefully help a bit.
NSA, ODNI, and CISA released a 32 page document detailing how to assess SBOMs as part of your risk program.
👋 this was a frustrating read. It can be summarized by “Emerging tools will help automate and scale.” which is basically what all of the conclusion points were… Why release a document if all you have to say is “wait for better tools to be created”. It doesn’t even mention OWASP’s dependency track.
That said, if you’re curious how future SBOM consumption tools will likely look, or if you’re working on this as a product/platform, it isn’t all bad.
Chris Siebenmann shared a nice overview of the domain expiry problem as it relates to Go modules. Specifically, Chris shares how a Go module can be taken over if and when it’s associated domain expires. For you Go developers out there, Chris shares your frustration for when a module changes domains as users are not notified. Fortunately, this only occurs if the maintainers lose access to the original domain.
👋 As Chris mentions, every system used for third party packages has some sort of namespace problem. I will say, I think the risk of malicious updates is downplayed in this post.
Checkmarx’s Yehuda Gelb dissects the numerous malicious pypi packages using the
pyobf naming convention.
👋 I really enjoy reading about malware and performing malware analysis, and there’s no shortage of these discoveries. That said, I don’t recall seeing any malicious dependencies specifically targeting MacOS; that must imply that it can’t be done (sarcasm). But in all seriousness, between using a mac and driving a manual car, I think I’m immune to threat actors. 🤣
Until Next Time! 👋
Hey, you made it to the bottom – thanks for sticking around!
Questions, ideas, or just want to chat? Slide into my inbox! 💌
If you think someone could benefit from this, don’t hesitate to forward.
See you next Monday!