Managing Vulnerabilities through SSDLC

Managing Vulnerabilities through SSDLC

Speakers: Luchi Stanescu, Security Engineering Manager, Canonical

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=bLmsdsxmJGE

Overview

In this insightful talk at VulnCon, Luchi Stanescu, Security Engineering Manager at Canonical, delves into the critical lessons learned from implementing a robust Security Software Development Life Cycle (SSDLC) within Canonical's diverse product ecosystem. The presentation articulates Canonical's structured approach to managing vulnerabilities, emphasizing that security is not a one-time fix but a continuous, iterative process. Stanescu challenges the notion of a world without cyber threats, asserting that such threats are often subtle and nuanced, necessitating a proactive and integrated security strategy.

The talk outlines Canonical's six-pronged SSDLC methodology, encompassing threat modeling, static code analysis, vulnerability scanning, penetration testing, vulnerability response, and comprehensive security documentation. Stanescu highlights the inherent challenges and "pain points" encountered during implementation, offering practical solutions and strategic decisions that proved effective. This discussion is particularly relevant for organizations striving to embed security deeply within their development processes, moving beyond reactive measures to cultivate a culture of continuous security awareness and improvement.

The importance of this talk lies in its practical, experience-driven approach to SSDLC. Stanescu shares actionable insights derived from real-world application, demonstrating how Canonical empowers product teams to own security, integrate automated tools, and establish clear processes for vulnerability management and communication. The emphasis on continuous iteration, tailored tool selection, and transparent documentation provides a valuable blueprint for any organization looking to mature its security posture and effectively manage the ever-evolving landscape of cyber threats.

Background

▶ Watch: Introduction to SSDLC and vulnerability management (0:00)

The pervasive and often subtle nature of cyber security threats necessitates a structured and proactive approach to software development. Unlike overt physical threats, digital vulnerabilities can lurk unseen, only to manifest as significant risks if left unaddressed. As Luchi Stanescu points out, the idea of a world without cyber threats is as fantastical as one with dinosaurs roaming freely – the threats are real, ever-present, and demand constant vigilance. This reality underpins the fundamental need for a Security Software Development Life Cycle (SSDLC).

An SSDLC integrates security considerations into every phase of the software development process, from initial design to deployment and ongoing maintenance. This contrasts sharply with traditional approaches where security is often an afterthought, "bolted on" at the end, leading to costly and often ineffective remediation efforts. Canonical's journey reflects a commitment to move beyond this reactive model, recognizing that vulnerabilities are an inherent part of software and will continuously emerge. The challenge, therefore, is not to eliminate them entirely but to manage them coherently and continuously.

Canonical's SSDLC is designed as an iterative, continuous cycle rather than a linear process. While steps are ordered to ensure logical dependencies and leverage outputs from previous stages, the entire cycle repeats frequently to adapt to evolving threats and system changes. The core components of Canonical's SSDLC, as presented by Stanescu, include Threat Modeling, Static Code Analysis, Vulnerability Scanning, Penetration Testing, Vulnerability Response, and a foundational layer of Security Documentation. This comprehensive framework aims to provide a holistic and consistent mechanism for identifying, assessing, mitigating, and communicating security risks across all products, whether internally developed or open-source projects with additional Canonical services.

Key Findings

▶ Watch: Vulnerability scanning: choosing tools and interpreting results (4:10)

Canonical's experience with implementing its SSDLC yielded several key findings and strategic decisions that proved crucial for success:

• Empowering Product Teams for Threat Modeling: A significant finding was that product teams are best placed to perform threat modeling. They possess the deepest understanding of their product's architecture and functionality. Canonical provides guidance and training to equip these teams with the necessary cybersecurity knowledge, enabling them to define scope, identify assets (crown jewels and stepping stones), map data flows and trust boundaries, and enumerate threats and controls. This approach ensures relevance and ownership, although defining scope and identifying implicit controls were noted as common pain points.

• Continuous Integration of Static Code Analysis: Integrating static code analysis (SCA) tools directly into the CI pipeline significantly lowers the barrier to entry for developers. This automation makes security checks a routine part of the day-to-day development process, leading to demonstrable improvements in code quality, tracked through metrics. However, it's crucial to understand that SCA tools, while valuable (e.g., Bandit for Python), do not find all security issues and can lead to a false sense of security if over-relied upon.

• Strategic Vulnerability Scanning: Canonical utilizes multiple off-the-shelf vulnerability scanners, interpreting and collating results based on the specific artifact being scanned (e.g., Ubuntu charms, snaps). A key insight is that scanners vary in their approaches and heuristics, requiring careful selection and testing. Furthermore, scanning must be continuous and periodic, not just at release time, as new vulnerabilities are constantly discovered. Teams must be trained to handle both true positives and false positives as routine business.

• Threat-Led Penetration Testing: Penetration testing is most effective when informed by a prior threat model. This "threat-led" approach allows third-party testers to focus on the most critical aspects and identified risks of a product, rather than merely uncovering known vulnerabilities that should have been addressed earlier. This strategy is also gaining regulatory traction, notably being mandated by the EU DORAP regulation for the financial sector.

• Vulnerability Response as Business as Usual: Stanescu emphasizes that vulnerabilities are inevitable, and organizations must treat their discovery and remediation as "business as usual," not a panic-inducing event. This involves defining a clear product lifecycle for support, establishing robust prioritization criteria (e.g., critical vs. low severity), considering mitigations as immediate responses (even before root cause fixes), and maintaining transparent, empathetic communication with users. Utilizing features like GitHub security advisories for embargoed disclosures is also critical.

• Security Documentation for Empowerment: Often overlooked, security documentation is highlighted as one of the most vital components. It ensures internal teams understand security requirements and empowers end-users to deploy and use products securely. Key elements include discussing identified risks (from threat modeling), covering information security implications, detailing security-sensitive functions (like authentication and cryptography), and providing practical how-to guides and hardening guides tailored for diverse deployment contexts.

Technical Deep Dive

▶ Watch: Strategic placement and focus of pentesting (4:55)

Canonical's SSDLC framework provides a structured and iterative approach to integrating security into product development. Each stage is designed to build upon the previous, fostering a comprehensive security posture.

1. Threat Modeling:

Canonical's in-house threat modeling methodology is specifically tailored for open-source projects and focuses on the CIA triad (Confidentiality, Integrity, Availability). The process empowers product teams, who best understand their products, to conduct the analysis.

• Define Target of Evaluation (Scope): Crucially, this involves not just what is in scope but also what is explicitly out of scope to prevent analysis paralysis. For example, when considering a Linux subsystem on Windows, the underlying Windows OS might be out of scope for the subsystem's threat model.
• Identify Assets (Crown Jewels & Stepping Stones):
• Crown Jewels: Critical assets with high CIA requirements (e.g., sensitive data, core functionality).
• Stepping Stones: Assets that, if compromised, could facilitate access to crown jewels (e.g., less critical services, configuration files).
• Connect Assets with Data Flows & Trust Boundaries: This step involves visualizing the system as a graph, with assets as nodes and data flows as edges. Trust boundaries are identified where trust levels change (e.g., between user input and a database). Drawing these diagrams is strongly encouraged for clarity.
• Identify and Quantify Threats: While threat catalogs can be useful, Canonical encourages teams to brainstorm potential threats, fostering a broader perspective. The goal is to identify threats to the CIA properties of the assets.
• Mitigating Controls: Document existing and planned controls that protect assets from identified threats. A common pain point is overlooking implicit controls (e.g., TLS for data in transit), which must be explicitly captured as they can fail or be broken.
• Residual Risk: After applying controls, assess the remaining risk. If too high, additional controls are needed.
• Continuous Iteration: Threat models are living documents. They must be reviewed and updated regularly, not just from scratch, but by analyzing changes since the last version and shifts in the operational context.

2. Static Code Analysis (SCA):

SCA tools are integrated into the Continuous Integration (CI) pipeline to provide automated, continuous code quality and security checks. This lowers the barrier for developers, making security a routine part of their workflow. Canonical tracks code quality improvements through metrics derived from SCA results. While tools like Bandit for Python are mentioned for security-specific issues, it's critical to understand that no single SCA tool is exhaustive. Relying solely on a "clean" SCA report can create a dangerous false sense of security, as these tools primarily find known patterns and may miss logical flaws or novel vulnerabilities.

3. Vulnerability Scanning:

Canonical employs multiple off-the-shelf vulnerability scanners for all distributed artifacts, including Ubuntu charms and snaps. The approach is to interpret and collate results from various scanners, selecting the most appropriate tool based on the artifact type, as different scanners have varying heuristics and efficacy.

• Dependency Management: Scanners are particularly useful for identifying known vulnerabilities in third-party dependencies.
• Continuous Scanning: Artifacts are scanned at release time and then periodically forever (or at least until end-of-life) because new vulnerabilities are constantly discovered (e.g., a "clean bill of health" today might not hold in two weeks).
• False Positives and True Positives: Teams are trained to differentiate and handle both, integrating this into their regular workflow.

4. Penetration Testing:

Canonical conducts threat-led penetration tests, where the scope is explicitly defined and informed by the product's threat model. This ensures that third-party security testers focus their efforts on the most critical assets and high-risk threat scenarios identified during threat modeling. This targeted approach is more efficient and effective than a broad, untargeted test. The practice aligns with emerging regulatory requirements, such as the EU DORAP regulation for the financial sector, which mandates threat-led penetration testing.

5. Vulnerability Response:

A coherent and consistent vulnerability response process is essential.

• Business as Usual: Vulnerabilities are an expected part of software. Panic is counterproductive; a calm, systematic approach is needed.
• Product Lifecycle: Clearly defined support periods for products are established, within which vulnerabilities will be addressed.
• Prioritization: Not all vulnerabilities are equal. A robust prioritization scheme ensures critical vulnerabilities are addressed immediately, while lower-severity issues are managed appropriately without halting all development.
• Mitigations vs. Root Cause Fixes: Product teams often prefer to fix the root cause, but in cases of public disclosure, providing immediate mitigations to users can be crucial for risk reduction, even if a full fix takes longer.
• Transparent Communication: Communication with users must be continuous and empathetic, not just a single announcement when patches are available. Users need to be kept abreast of developments and advised on how to address issues.
• Security Policy & GitHub Advisories: A clear security policy guides external vulnerability disclosure. Canonical leverages GitHub security advisory features to facilitate embargoed disclosures from third parties, allowing for coordinated remediation before public release.

6. Security Documentation:

Often underrated, security documentation is paramount for transparency and user empowerment.

• Persona-Driven: Documentation considers different user personas (e.g., system administrators, end-users) and their specific security concerns.
• Risk Discussion: Directly discusses risks identified during threat modeling, making users aware of potential issues.
• Information Security: Covers implications of data loss, retention, or inadvertent disclosure.
• Security-Sensitive Functions: Provides detailed guidance on critical functions like authentication and cryptography. Cryptography, in particular, requires specific details (e.g., "what encryption? how?") beyond just stating "we use encryption," as it's a constantly evolving field.
• How-To Guides & Hardening Guides: These are practical, actionable guides:
• Checklists for secure product usage.
• Instructions for common security functions (authentication, authorization, backups).
• Hardening guides that explain what "knobs to turn" to secure a product within a specific deployment context, acknowledging that a "one-size-fits-all" product is impossible. Examples of public documentation for Canonical's MAAS and Juju products are provided.

Demo / Proof of Concept

▶ Watch: Security documentation: transparency and user empowerment (6:20)

The talk focuses on process, methodology, and lessons learned rather than a live demonstration of a vulnerability or a technical proof of concept. While the speaker alludes to public documentation examples for Canonical's MAAS and Juju products, there was no explicit demo or PoC shown during the presentation. The emphasis was on the practical application of the SSDLC framework and the results observed through its implementation.

Defensive Implications

▶ Watch: Threat modeling: best performed by product teams (8:40)

The insights from Canonical's SSDLC journey offer several critical defensive implications for organizations aiming to strengthen their security posture:

1. Integrate Security Early and Continuously: The most fundamental takeaway is to embed security at every stage of the Software Development Life Cycle (SDLC), making it a continuous, iterative process rather than a one-off audit. This proactive approach prevents costly remediation later.
2. Empower Product Teams with Security Knowledge: Security should not solely reside with a dedicated security team. Organizations should train and empower their product development teams to perform tasks like threat modeling. By providing methodologies, guidance, and examples, developers can take ownership of security, leveraging their deep product knowledge for more effective risk identification.
3. Automate Security Testing in CI/CD: Implement static code analysis (SCA) tools (e.g., Bandit) directly into CI/CD pipelines. This automation lowers the barrier for developers, ensures consistent security checks, and provides trackable metrics for code quality improvement. However, defenders must communicate the limitations of these tools to prevent a false sense of security.
4. Adopt a Multi-Scanner Strategy for Vulnerability Scanning: Relying on a single vulnerability scanner is insufficient. Defenders should use multiple off-the-shelf scanners, carefully selecting and testing them based on the specific artifacts (e.g., Docker images, packages) being scanned. Continuous, periodic scanning (not just at release) is crucial, as new vulnerabilities are constantly discovered in dependencies.
5. Leverage Threat Models for Targeted Penetration Testing: Prioritize threat-led penetration testing. By providing external testers with detailed threat models, organizations can ensure that pentests focus on the most critical assets, data flows, and identified risks, yielding more actionable and relevant findings. This aligns with modern regulatory expectations like EU DORAP.
6. Establish a Robust, "Business as Usual" Vulnerability Response: Develop a clear, consistent vulnerability response plan. This includes defining product lifecycles, establishing a clear prioritization framework for vulnerabilities (e.g., CVSS, exploitability), and having a strategy for both immediate mitigations and long-term root cause fixes.
7. Prioritize Transparent Communication and Documentation: Security documentation is a critical defensive asset. Create comprehensive security documentation that caters to different user personas, discusses identified risks, details security-sensitive functions (authentication, cryptography), and provides practical how-to guides and hardening guides. This empowers users to configure and deploy products securely, reducing the attack surface in diverse operational contexts. Utilize features like GitHub security advisories for responsible, embargoed disclosures.

Key Takeaways

• Security is a Continuous Cycle: SSDLC is not a one-time project but an ongoing, iterative process that must adapt to evolving threats and system changes.
• Empower Product Teams for Threat Modeling: Developers and product teams, with proper guidance, are best equipped to identify and model threats to their own products, fostering ownership and deeper understanding.
• Automate and Integrate Security Tools: Embedding static code analysis and vulnerability scanning into CI pipelines makes security checks routine, improving code quality and catching issues early.
• Contextualize Security Testing: Threat-led penetration testing, informed by detailed threat models, provides more effective and targeted security assessments than generic tests.
• Treat Vulnerabilities as Business as Usual: Establish a consistent, prioritized vulnerability response process to handle disclosures calmly, communicate transparently, and consider immediate mitigations alongside long-term fixes.
• Comprehensive Security Documentation is Crucial: Well-written documentation, including hardening guides and how-to's for security-sensitive functions, empowers users to deploy and operate products securely in their specific environments.

About the Speaker(s)

Luchi Stanescu is a Security Engineering Manager at Canonical. In this role, he leads efforts to integrate security into the software development lifecycle for Canonical's products. His expertise lies in developing and implementing robust SSDLC processes, providing guidance to product teams, and fostering a culture of continuous security improvement. His experience at Canonical, a prominent open-source software company, gives him a practical perspective on managing vulnerabilities across a diverse range of projects and technologies.