Loading story…
A new open-source Software Factory Security Framework (SF²), developed by Julie Davila of GitLab, has been introduced to help organizations strategically scale their security operations. The framework emphasizes resource allocation over simply increasing staff and outlines five core security responsibilities for software-producing organizations: supply chain security, process stewardship, runtime protection, third-party risk management, and continuous learning. SF² provides actionable guidance for each area, such as dependency monitoring and pipeline security controls, aiming to improve both security outcomes and business alignment.
Simultaneously, the adoption of Software Bill of Materials (SBOMs) remains a contentious issue in the software industry. While SBOMs are recognized as essential for addressing supply chain security, their practical implementation is hampered by ecosystem complexity and incomplete coverage, especially in open-source projects. Companies like Docker have integrated SBOMs and provenance verification into their container images, but many organizations still struggle to generate comprehensive SBOMs for all software components. Recent updates from CISA have increased requirements for SBOM completeness, highlighting the ongoing challenges and ambivalence within the industry regarding their effectiveness.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
4 events from the most recent confirmed update back to the earliest known activity.
Julie Davila of GitLab developed the open-source Software Factory Security Framework (SF²) to help organizations scale security operations strategically through stewardship, posture assessment, and investment planning.
Docker incorporated complete SBOMs alongside provenance claims meeting SLSA Level 3 in its Docker Hardened Images, signaling a concrete vendor implementation of software supply-chain transparency controls.
The Linux Foundation released an update to the Supply-chain Levels for Software Artifacts framework, identified as SLSA 1.2, as part of broader efforts to strengthen software build-pipeline security.
CISA updated its software bill of materials guidance to require machine-readable formats such as SPDX or CycloneDX, reflecting a push toward more standardized SBOM production and exchange.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
2 references tracked. Mallory keeps watching after this page renders.
Map 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.
Organizations are moving beyond traditional vulnerability management and treating software transparency as a core security requirement, with **Software Bills of Materials (SBOMs)** becoming central to software supply chain defense. Reporting on preparations for the EU **Cyber Resilience Act (CRA)** says manufacturers of products with digital elements will be required to create, maintain, and when necessary provide inventories of software components, driving broader adoption of SBOM tooling and automation. The shift is intended to improve visibility into open-source libraries and third-party dependencies so teams can identify vulnerable packages, assess supplier risk, and respond faster to newly disclosed flaws. Security practitioners are also pushing companies to use SBOMs as an operational tool rather than a compliance document. Group-IB researcher Anastasia Tikhonova said organizations should apply SBOM data continuously for vulnerability triage, vendor access reviews, identity monitoring, and incident response, as modern supply chain attacks increasingly link phishing, ransomware, and data breaches through inherited trust relationships. She warned that attackers’ use of AI is compressing attack timelines from weeks to minutes, increasing the need to prioritize exposed systems, define compromise windows, contain stolen credentials, and score vendor risk by access level and potential blast radius.
Jul 10, 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
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