• 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