- CramHacks
- Posts
- [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.
Shoutout to any new subscribers who attended my talk for either FS-ISAC or OWASP Atlanta this past week. For those wondering, the titles were:
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!
-Kyle