Episode 415 - The Risk Story – Software Supply Chain Security

We sat down with Cassie Crosley to explore the complexities of supply chain risks, particularly within the realm of operational technology (OT).

Comprehensive Supply Chain Security - Crosley detailed the various stages in the supply chain—design, development, and fabrication—where both deliberate and accidental abuses can occur. Each stage presents unique risks, such as compromised design specifications, development flaws, or issues during fabrication. She emphasized that securing the software supply chain requires a holistic approach that goes beyond protecting just software; it must also include firmware and hardware. For example, when working with an Intel chip, securing both the software and firmware associated with that chip is critical. Firmware, which operates at a low level on hardware, is vital for overall system security. Any vulnerabilities in firmware can significantly compromise the entire system, making it essential to secure it alongside software and hardware.

Challenges in Secure by Design - Crosley also noted that while "secure by design" principles often originate from an IT perspective, they may not seamlessly translate to OT environments. This disparity creates challenges, as certain IT security measures, like multi-factor authentication (MFA), may not be practical or necessary in OT due to specific operational needs. Additionally, OT devices are often multi-generational, increasing the risk of outdated security designs. OT systems, such as programmable logic controllers (PLCs) used in industrial settings, have distinct requirements and constraints, necessitating tailored security approaches.

Automated Patching Issues - Crosley highlighted that automated patching in OT environments can pose safety concerns and lead to downtime. Unlike IT systems where automated updates are common, OT systems often require careful, manual handling to avoid disrupting critical processes. Automated patching can interfere with vital safety mechanisms, underscoring the need for controlled and deliberate update management.

SBOM (Software Bills of Materials) - Crosley pointed out that while generating accurate Software Bills of Materials (SBOMs) for modern technologies is relatively straightforward, it becomes more complex for multi-generational OT products due to outdated build practices and the limitations of current scanning tools. While scanners effectively identify open-source components, they struggle with proprietary or commercial libraries, and discrepancies in version identification can be problematic, particularly if certain versions have known vulnerabilities.

Role of AI in Software Development – She also pointed out how AI can quickly analyze vast amounts of data, identifying risks and correlations between projects that would take humans much longer to detect. For example, AI can track a maintainer's contributions across multiple projects to spot potential security risks, such as involvement in both malicious and non-malicious projects. AI is also increasingly offering developers precise guidance on addressing specific vulnerabilities. Instead of generic suggestions, AI now recommends the best code modifications for a given context, speeding up development and enhancing code security.

Supplier Assessment - Crosley advised that supplier assessments should focus on specific aspects of vulnerability management and product security rather than generic compliance questions. It's crucial to inquire about suppliers' vulnerability management practices and their methods for ensuring product security. She emphasized the importance of transparency from suppliers regarding their manufacturing processes, product variations, and supply chain details, advocating for detailed questions to effectively understand and mitigate risks.

Positive Cultural Shift - Crosley shared an encouraging trend where companies are increasingly prioritizing supply chain security. A notable example is a supplier that created a position for a Product Security