Loading story…
CISA released "Open Source Software: Security Principles and Practices", a guide for federal agencies on securely using, evaluating, developing, and publishing open-source software across its full lifecycle. The guidance says open-source software is not inherently more or less risky than proprietary software, but agencies should tailor risk management to open-source development models by improving asset tracking, patching, vulnerability management, and software bill of materials (SBOM) practices.
The document introduces the C4 Framework for assessing project trustworthiness and includes recommendations on secure development, contributing to upstream projects, and preserving government reuse rights in custom software contracts. CISA also highlights added scrutiny for so-called open-source or open-weight AI systems, warning that licensing and transparency gaps can make it harder for agencies to evaluate trustworthiness and security.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
1 event from the most recent confirmed update back to the earliest known activity.
CISA published guidance titled "Open Source Software: Security Principles and Practices" to help federal agencies securely use, evaluate, and publish open-source software. The guide covers lifecycle risk management, vulnerability handling, SBOM use, secure development, trust assessment, and special considerations for open-weight AI systems.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
3 references tracked. Mallory keeps watching after this page renders.
helpnetsecurity.com
Open sourcecyberscoop.com
Open sourcecisa.gov
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Open-source software forms the backbone of much of today's digital infrastructure, powering browsers, applications, and critical business systems. Security leaders are increasingly aware of the risks associated with integrating open-source components into their environments, as vulnerabilities can be present even in widely used and actively maintained projects. A recent study by James Cusick at Ritsumeikan University compared the security of open-source and proprietary software by scanning millions of lines of code. The analysis revealed that large open-source projects like Chromium, despite their robust contributor communities, still contained over 1,400 potential issues, though only a few were deemed critical or high severity. In contrast, smaller open-source projects such as Genann exhibited a much higher density of potential issues, with one problem for every 27 lines of code. Proprietary software, while not immune, generally fell between these extremes, with most issues rated as medium or low severity. These findings highlight the importance of static code scanning and rigorous review processes for all software, regardless of its origin. The integration of open-source components without thorough vetting can introduce significant supply chain risks, as vulnerabilities may remain undetected and exploitable. In response to these challenges, regulatory frameworks like the European Union's Cyber Resilience Act (CRA) have been developed to enhance software security and transparency. According to Greg Kroah-Hartman, a leading Linux kernel maintainer and member of the CRA working group, the Act has evolved to be more accommodating to open-source developers. The CRA now requires producers of products with digital elements to document, secure, and maintain their software supply chains, including the generation of Software Bills of Materials (SBOMs) and proactive vulnerability management. While initial drafts of the CRA raised concerns among open-source communities about potential legal liabilities, subsequent revisions have made the regulations more palatable and beneficial for open-source contributors. Organizations like the Linux Foundation and Mozilla are required to comply with these rules, but individual contributors are generally exempt unless they are acting as commercial entities. The CRA aims to foster greater transparency and accountability in software development, ultimately benefiting both open-source and proprietary ecosystems. Security leaders are encouraged to adopt comprehensive code scanning and supply chain management practices to mitigate the risks associated with open-source software. The evolving regulatory landscape underscores the need for organizations to stay informed and proactive in addressing software security challenges. By combining technical diligence with compliance efforts, businesses can better protect themselves against the hidden risks inherent in modern software supply chains. The ongoing dialogue between regulators, open-source communities, and industry stakeholders is shaping a more resilient and secure digital environment for all.
Jun 29, 2026
CISA and partner agencies in the United States and 13 allied countries released updated guidance for the minimum elements of a Software Bill of Materials, replacing the 2021 NTIA baseline with broader requirements intended to improve software transparency and supply chain risk management. The revised framework preserves the original core principles but adds fields for component hash information, license data, author or digital signature, SBOM version, data format details, generation context, and tool metadata, while removing elements such as Access Control and SWID Tags. Officials said the changes were shaped by software supply chain security developments and feedback gathered during a 2025 public comment period. The update is designed to make SBOMs more useful for automated vulnerability management and procurement decisions, and it explicitly notes that some software categories need additional treatment beyond the general baseline. In parallel, the G7 Cybersecurity Working Group published guidance on the minimum elements for an AI-focused SBOM, providing actionable recommendations for public- and private-sector stakeholders to improve transparency across the AI supply chain. The combined guidance signals a broader international push to standardize software component disclosure for both conventional software and AI systems, with future work expected on SaaS, AI-specific components, SBOM trustworthiness, and links to formats such as **VEX** and **CSAF**.
Jul 31, 2026
CISA, the NSA, and international partners published joint guidance urging software manufacturers and online service providers to formalize **coordinated vulnerability disclosure (CVD)** programs for working with external security researchers. The guidance calls for organizations to publish a clear vulnerability disclosure policy, define internal processes for receiving, triaging, remediating, and disclosing reported flaws, and assign **CVE** identifiers where appropriate to improve tracking and transparency. The document also recommends using third-party coordinators such as **CISA** or national **CSIRTs** when organizations need support handling disclosures, and it highlights **safe harbor** language to protect good-faith researchers from legal action. CISA said the practices can help vendors strengthen product security and give customers and critical infrastructure operators a way to assess a supplier’s maturity in handling vulnerability reports and remediation.
Jul 16, 2026