Applying Cybersecurity Regulations and Industry Standards to Open Source Projects

Applying Cybersecurity Regulations and Industry Standards to Open Source Projects

Speakers: Luchi Stanesco, Security Engineering Manager, Canonical

Conference: VulnCon

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

Overview

In an era where open source software forms the bedrock of nearly every technological stack, the intersection of open source development with stringent cybersecurity regulations and industry standards presents a complex challenge. Luchi Stanesco, a Security Engineering Manager at Canonical, tackled this critical topic at VulnCon, presenting a compelling argument for how these seemingly disparate worlds can not only coexist but mutually benefit. The talk, titled "Applying Cybersecurity Regulations and Industry Standards to Open Source Projects," delves into the practicalities of bridging the gap between prescriptive regulatory frameworks and the often-decentralized, volunteer-driven nature of open source development.

Stanesco’s core premise is that while regulations are not designed to be imposed on open source projects, the underlying security best practices they enshrine are universally applicable and highly beneficial. Regulated environments extensively use open source, yet they lack consistent methods to assess its security against their compliance obligations. Conversely, open source projects, often driven by a deep commitment to security, can leverage these established standards to enhance their own practices, improve transparency, and foster greater trust among users, especially those in highly regulated sectors.

The significance of this discussion cannot be overstated. As global cybersecurity legislation like the Cyber Resilience Act (CRA) increasingly impacts software supply chains, understanding how open source fits into this landscape is paramount. Stanesco advocates for moving beyond mere "tick-box exercises" and embracing the spirit of regulations to cultivate genuinely useful security improvements, thereby empowering both open source maintainers and the organizations that depend on their work.

Background

▶ Watch: Introduction: Applying regulations to open source projects (0:00)

The pervasive nature of open source software means it is embedded in virtually every technological solution, from critical infrastructure to consumer devices. This ubiquity extends even to highly regulated environments, which rely heavily on open source components. However, the tools and frameworks traditionally used by these regulated entities to assess the security of their software supply chain, such as vendor security questionnaires, are often ill-suited for the unique context of open source projects. These tools are typically designed for commercial vendors with established corporate structures, legal departments, and a clear chain of accountability, making their direct application to open source impractical and often impossible.

This disconnect creates a significant problem: regulated organizations struggle to consistently evaluate the security posture of their open source dependencies against their compliance requirements, leading to inconsistencies in risk assessment. On the other hand, while the open source ecosystem has developed its own robust security initiatives – notably from the OpenSSF (Open Source Security Foundation), including its Best Practices Badge Program and Scorecard project, as well as guidance on regulations like the CRA – these are specifically tailored for open source and don't always directly "speak the language" of traditional regulatory frameworks.

The speaker emphasizes that cybersecurity regulations, despite their formal and often legalistic language, are fundamentally built upon generic security best practices advocated by experts across the industry. This shared foundation suggests a potential for convergence. Stanesco’s approach is to explore how these two worlds can fit together, offering a pathway for regulated environments to better understand and integrate open source into their compliance strategies, and for open source projects to proactively align with and benefit from established industry security standards. The goal is not to burden open source maintainers with legal obligations, but to foster greater transparency and enable informed decision-making for all stakeholders.

Key Findings

▶ Watch: Overview of NCSC, CISA, and OpenSSF assessment tools (3:30)

The central finding of Luchi Stanesco's talk is the demonstrable feasibility of mapping traditional cybersecurity regulatory criteria to established open source security practices. Despite the differing language and scope, a significant overlap exists, indicating that the underlying principles are universal. Stanesco's manual mapping exercise served as a proof of concept, revealing that a substantial portion of criteria from mainstream regulatory tools can be directly correlated with existing OpenSSF initiatives.

Specifically, the mapping showed:

• NCSC Vendor Security Assessment (VSA): 32 out of its 58 criteria items could be directly mapped to OpenSSF Best Practices criteria or OpenSSF Scorecard tests.
• CISA Vendor Supply Chain Risk Management (SCRM) Template: 13 out of its 16 questions relevant to security could be directly mapped to OpenSSF criteria or tests.

This indicates that over half of the NCSC VSA's criteria and a vast majority of the CISA SCRM template's security-focused questions are already addressed, or can be addressed, by existing open source security frameworks. The unmapped criteria, rather than representing an insurmountable gap, highlight areas where open source projects can learn and adapt their practices to further enhance their security posture and transparency, even if the literal wording of the regulation doesn't apply.

Crucially, the talk proposes a three-step solution for bridging this gap:

1. Mapping: Creating formal mappings between regulatory tools/standards and open source software tools (like OpenSSF initiatives).
2. Regulatory Approval: Seeking a "stamp of approval" from regulatory agencies to validate these mappings, thereby providing official recognition that adhering to open source best practices can satisfy regulatory requirements.
3. Continuous Tracking and Publication: Maintaining and continuously updating these mappings and publishing the compliance data, fostering transparency and enabling informed decision-making for users of open source software.

Ultimately, the key finding is an optimistic one: the perceived chasm between open source and regulation is not as wide as it seems. Through strategic mapping, collaboration with regulatory bodies, and a commitment to transparency, the open source ecosystem can proactively address regulatory concerns, empowering its continued growth and adoption in all sectors.

Technical Deep Dive

▶ Watch: Demonstrating regulatory tool compatibility with open source (4:40)

Stanesco's presentation delved into a detailed comparison of several key security frameworks, dissecting how their criteria align or diverge when applied to the open source context. The frameworks under examination included two prominent regulatory/industry standards and two leading open source security initiatives:

Regulatory and Industry Standards:

1. NCSC Vendor Security Assessment (VSA): Developed in support of the UK's Telecom Security Act, this framework's stated goal is to advise on assessing the security of "network equipment." Stanesco clarified that "network equipment" in this context broadly refers to anything processing telecommunications, including servers. It comprises 58 criteria items spread across 10 categories, often being quite prescriptive. An example criterion is "the vendor makes use of modern heap protection mitigations," which demands specific technical implementations.

1. CISA Vendor Supply Chain Risk Management (SCRM) Template: This US-based template aims to standardize the communication of ICT supply chain risk posture. It's broader in scope than the NCSC VSA, with 8 categories that extend beyond purely technical security to include aspects like personnel and physical security. The CISA template is generally more generic in its questions. For instance, the closest equivalent to the NCSC's heap protection criterion is "does your organization configure the compilation and build processes to improve executable security?" This provides less specific guidance, allowing for broader interpretation.

Open Source Security Initiatives:

1. OpenSSF Best Practices Badge Program: This program promotes security best practices across the open source ecosystem. It features 143 criteria organized into three tiers: passing, silver, and gold badges. Projects self-certify their adherence, providing documented evidence, though some automated tests pre-fill parts of the questionnaire. The tiers are cumulative, requiring all passing criteria to be met before silver, and so on.

1. OpenSSF Scorecard: This is a set of automated tests designed to assess the security posture of open source projects. It provides a score that helps users make informed decisions about dependencies, allowing for customization based on which criteria they deem most important. Like the Best Practices program, it is rooted in general security best practices.

Mapping Exercise and Insights:

Stanesco's core technical contribution was the manual mapping of criteria from the NCSC VSA and CISA SCRM template to the OpenSSF Best Practices and Scorecard tests. This exercise demonstrated that:

• Many regulatory criteria have direct or highly analogous counterparts in open source best practices. For example, the NCSC VSA's requirement for a "version controlled code repository" directly maps to the OpenSSF Best Practices' passing badge criterion that "the project must have a version control source repository that is publicly readable and has a URL."
• Other mappings require a nuanced interpretation of regulatory language. The NCSC VSA's "vendor has a process for issuing remediation" criterion, referring to vulnerabilities, aligns with the OpenSSF Best Practices' silver badge requirement for "a documented process for responding to vulnerability reports." Stanesco highlighted the subtle difference: remediation might imply a patch, while response ensures acknowledgement and action, regardless of the specific solution.

Unmapped Criteria and Learning Opportunities for Open Source:

The 26 NCSC VSA criteria items that did not directly map to OpenSSF initiatives were grouped into categories by Stanesco, revealing valuable learning opportunities for open source projects:

1. Security Declaration:

• NCSC VSA Examples: Product lifecycle identification, single primary release train, minimal other versions/forks, plans for security improvement.
• Open Source Relevance: While stopping forks is antithetical to open source, communicating a clear release lifecycle (e.g., Python's website showing support timelines) is crucial for user education and setting expectations. Explicitly stating how vulnerabilities are handled (e.g., "only fix vulnerabilities in the latest release") empowers users to make informed update decisions. Such declarations also guide contributors on security handling. OpenSSF Best Practices already includes elements like requiring primary developers to "know how to design secure software."

1. Code Quality:

• NCSC VSA Examples: No unsafe functions, limited redundant/duplicate code, minimized code complexity, good comments.
• Open Source Relevance: Stanesco cited research correlating code complexity with vulnerabilities. Good code quality not only reduces security risks but also encourages contributions. The concept of "unsafe functions" is vital, though defining a universal list is challenging. Tools like Bandit, a static code analysis tool for Python, maintain blacklists (e.g., flagging the eval function as insecure, B307), demonstrating how this can be operationalized.

1. Segregation of Development Environment and Testing Rigor:

• NCSC VSA Examples: Development environment segregated from corporate network and protected from the internet; developers cannot modify the build environment to hide issues.
• Open Source Relevance: While "corporate network" doesn't apply, the spirit of least privilege and protecting code integrity is highly relevant. Supply chain attacks, such as those exploiting GitHub Actions or the notorious XZ Utils backdoor (CVE-2024-3094), underscore the need for secure build environments and controlled access. For open source, where confidentiality of the codebase is not an issue, integrity becomes paramount.

1. Security Best Practices (General):

• NCSC VSA Examples: Least privilege code execution, no undocumented administrative mechanisms, no hard-coded passwords or access keys, no default credentials, easy product hardening.
• Open Source Relevance: These are universal best practices. The concept of "secure by default" is highlighted as beneficial for end-users, reducing configuration effort and promoting harmonized deployments. Clear documentation for hardening configurations (as practiced by Canonical within its SDLC, for example, identifying specific security-relevant knobs) is essential for advanced users.

1. Testing:

• NCSC VSA Examples: Security functionality tested, negative testing.
• Open Source Relevance: Often, testing focuses on "happy paths." Stanesco emphasized that security relies on testing "exceptional data flows" and "error paths"—precisely what attackers exploit. Explicit security tests prevent regressions and ensure validations remain effective.

1. Response:

• NCSC VSA Examples: Root cause analysis for issues, transparent patching of security issues, presence of a Product Emergency Response Team (PERT).
• Open Source Relevance: While a formal PERT might be unfeasible for small projects, having coherent, reproducible processes for vulnerability handling is critical. Open source projects deeply care about security, and shifting vulnerability handling from a panic-inducing event to "business as usual" is essential. Transparency in root cause analysis and patching is innate to open source ethos and crucial for user trust and informed decision-making.

Stanesco also briefly highlighted CISA SCRM questions that align with these themes, such as "Does your organization reuse existing well secured software and hardware components when feasible?" (dependency management), "Does your organization document and communicate security control requirements?" (security documentation), and "Does your organization configure offerings to implement secure settings by default?" (secure by default). These examples reinforce the universality of the underlying security principles.

Demo / Proof of Concept

▶ Watch: Detailed look at NCSC Vendor Security Assessment (6:50)

The core "demo" or proof of concept presented by Luchi Stanesco was a methodical, manual mapping exercise. Rather than a live software demonstration, the speaker showcased the results of her analytical work, illustrating how specific criteria from established regulatory frameworks directly align with, or can be interpreted in the context of, open source security best practices.

Stanesco presented slides detailing this mapping, although for the sake of time during the live talk, she only highlighted key examples. The concrete evidence of this mapping effort included:

• Quantitative Results: The speaker explicitly stated that 32 out of the 58 criteria from the NCSC VSA could be directly mapped to OpenSSF Best Practices criteria or OpenSSF Scorecard tests. Similarly, 13 out of 16 security-relevant questions from the CISA Vendor SCRM Template were found to have direct correlations. These statistics serve as tangible proof that such a cross-referencing is not only possible but yields significant overlap.
• Illustrative Examples: Stanesco walked through specific examples, such as the NCSC VSA's requirement for a "version controlled code repository" mapping directly to an OpenSSF Best Practices criterion. Another example involved comparing the NCSC's "process for issuing remediation" with OpenSSF's "documented process for responding to vulnerability reports," demonstrating how the spirit of a regulatory requirement can be met even if the exact wording differs.
• Discussion of Unmapped Criteria: Crucially, the "demo" also involved a detailed discussion of the criteria that did not directly map. Instead of dismissing these, Stanesco interpreted them as opportunities for open source projects to enhance their practices. This included categories like "Security Declaration," "Code Quality," and "Segregation of Development Environment," where the underlying principles (e.g., communicating lifecycles, reducing complexity, least privilege) were shown to be highly relevant to open source, even if the literal regulatory language (e.g., "corporate network") did not apply.

This rigorous analytical approach, backed by specific numbers and conceptual interpretations, served as a compelling demonstration that a practical bridge can be built between the often-disparate worlds of cybersecurity regulations and open source development.

Defensive Implications

▶ Watch: Detailed look at CISA STRM template (8:15)

The insights from Luchi Stanesco's talk offer crucial defensive implications for both organizations consuming open source software in regulated environments and for open source projects themselves.

For Regulated Organizations (Consumers of Open Source):

1. Consistent Risk Assessment: Regulated entities should move away from treating open source components as an unassessable "black box." By leveraging or contributing to mappings between regulatory standards (like NCSC VSA or CISA SCRM) and open source-specific security frameworks (like OpenSSF Best Practices and Scorecard), organizations can achieve a consistent and comparable risk assessment across their entire software supply chain, regardless of whether components are commercial or open source.
2. Informed Dependency Management: Organizations should actively use tools like OpenSSF Scorecard to evaluate the security posture of their open source dependencies. Rather than just looking at a raw score, understanding the composition of the score and customizing criteria based on internal risk appetite is key.
3. Advocate for Mappings: Enterprises should encourage regulatory bodies to formally recognize these mappings. A "stamp of approval" from regulatory agencies would streamline compliance efforts and provide clarity on how open source usage aligns with legal obligations.
4. Promote Transparency: By asking open source projects for clearer security declarations, documented vulnerability response processes, and hardening guides, organizations can drive greater transparency and enable better informed decisions about which projects to adopt and how to configure them securely.

For Open Source Projects (Maintainers and Contributors):

1. Embrace OpenSSF Initiatives: Projects should actively pursue OpenSSF Best Practices badges (aiming for Silver or Gold) and ensure their projects perform well against OpenSSF Scorecard tests. These provide a recognized, standardized way to demonstrate security commitment.
2. Proactive Security Communication: Open source projects should clearly communicate their security posture. This includes:

• Release Lifecycles: Explicitly stating how long releases are supported and for which versions security updates will be provided (e.g., "only latest release receives fixes"). This educates users and manages expectations.
• Vulnerability Response: Documenting a clear, reproducible process for handling vulnerability reports, moving from panic-driven reactions to a "business as usual" approach. Transparency in root cause analysis and patching is crucial.
• Hardening Guides: Providing specific documentation on security-relevant configuration options, enabling users to easily harden their deployments without needing to read entire manuals.

1. Adopt "Secure by Default": Where feasible, projects should configure their offerings to implement secure settings by default. This significantly reduces the attack surface for end-users who might not have the expertise or time to configure security settings manually.
2. Focus on Code Quality and Integrity: While "corporate network segregation" might not apply, the principles of least privilege, minimized code complexity, and robust security testing are paramount. Projects should:

• Reduce code complexity (which correlates with fewer vulnerabilities).
• Define and avoid "unsafe functions" (potentially using static analysis tools like Bandit).
• Implement strong testing rigor, including negative testing (testing error paths) to identify security regressions.
• Secure their build and contribution pipelines against supply chain attacks (e.g., securing GitHub Actions workflows).

1. Foster Transparency: Open source's inherent transparency is a defensive strength. Projects should continue to be open about security discussions, commit histories, and vulnerability fixes, empowering users to understand the security posture of their dependencies.

By actively engaging with these defensive implications, both sides of the open source supply chain can build a more secure and trustworthy ecosystem, allowing open source innovation to thrive even under increasing regulatory scrutiny.

Key Takeaways

• Regulations Are Not for Imposition, But for Guidance: Cybersecurity regulations are not meant to be imposed directly on open source maintainers, but rather provide a framework of universal security best practices that are beneficial for all software development.
• Ubiquitous Open Source in Regulated Environments: Open source software is used extensively even in highly regulated sectors, necessitating a standardized approach to assess its security against compliance requirements.
• Bridging the Gap Through Mapping: It is demonstrably possible to map criteria from traditional regulatory tools (like NCSC VSA and CISA SCRM) to open source-specific security frameworks (like OpenSSF Best Practices and Scorecard), enabling consistent risk assessment.
• Learning from Regulatory Principles: Open source projects can significantly enhance their own security posture and transparency by interpreting the spirit of regulatory criteria (e.g., least privilege, secure by default, robust testing, clear communication) and applying them to their unique context.
• Transparency and Communication are Paramount: Clear communication about release lifecycles, vulnerability response processes, hardening guides, and overall security posture is crucial for open source projects to educate users and foster trust, especially in regulated environments.
• Enabling Informed Decision-Making: The ultimate goal of aligning open source with security standards is to provide users with the necessary information to make informed decisions about their dependencies, ensuring the secure and confident adoption of open source software.

About the Speaker(s)

Luchi Stanesco is a Security Engineering Manager at Canonical. With a strong background in security engineering, she brings a practical, technical perspective to complex challenges like the intersection of open source and cybersecurity regulations. Stanesco began her presentation with a clear disclaimer, stating she has "no legal training" and that her advice should not be taken as legal counsel. This highlights her focus on the engineering and best-practice aspects of security, rather than the legal interpretation of regulations, emphasizing what is genuinely useful and actionable for the technical community. Her insights are drawn from hands-on experience in managing security within a major open source company.