ActiveState Your One Stop For Secure Trusted Open Source

CISA's New Disclosure Guidance and the End of the Zero-CVE Report: What to Actually Tell Your Board  The government just told every vendor what a defensible vulnerability process looks like. A raw CVE count was never going to be it. TL;DR CISA, the NSA, and international partners published joint guidance directing vendors to formalize vulnerability disclosure: clear policies, defined testing scope, ongoing researcher communication, and a repeatable process from report to fix to advisory. The guidance sets a new floor: a defensible vulnerability process is now a stated government expectation, not an optional best practice. Separately, renewed attention on the "zero-CVE" problem confirms that a package with no known CVEs can still carry undisclosed flaws, malicious code, or a compromised maintainer that a CVE scanner would never catch. ActiveState's own remediation SLA, 5 business days for critical CVEs, 10 for high severity, 30 for everything else, is the kind of spec...

  The Open Source Question Coming Due in September EU CRA disclosure obligations start in about two months. Most finance and security leaders have not rehearsed the answer. In roughly two months, the EU Cyber Resilience Act's first disclosure obligations take effect. Any organization with a product in scope will need to report actively exploited vulnerabilities within 24 hours, for products already on the market, not just new ones. Most finance and security leaders have not rehearsed what that report would actually say if they had to produce it today. That is not a compliance detail. It is a rehearsal problem, and rehearsal problems are the ones that get discovered at the worst possible moment, in front of the worst possible audience. Here is the exercise I would run before September, not after. Pick one dependency in your environment, any one, and try to answer three questions in writing: who decided this was acceptable to run, what would you show a regulator who asked you to do...

Discovery Is Outrunning Remediation Everywhere. That Is Not Just a Technology Problem. A model found 1,596 unpatched vulnerabilities in open source projects last month. The industry’s answer was more infrastructure for finding problems. That was never the part that was broken. Anthropic, Google, OpenAI, Microsoft, and more than a dozen other organizations just did something companies rarely do voluntarily. They pooled money into a shared body, called Akrites and hosted by the Linux Foundation, because none of them could keep pace with open source vulnerability discovery and remediation on their own. Organizations build shared infrastructure at this speed for one reason. A risk got too expensive for any single balance sheet to absorb quietly. That is what a captive insurance pool is. A group of companies decides a risk is real and common enough that carrying it alone costs more than carrying it together. Nobody calls that admission a taskforce. They call it underwriting, and they usual...

Open Source Compliance Now Has a Deadline. Accountability Now Has a Name. The US federal safety net that followed Log4j has thinned in the same window the EU Cyber Resilience Act wrote obligations for commercial users of open source software into law, with reporting requirements beginning September 2026. The accountability for what enters your products is moving toward the organizations that consume it, on someone else's timeline. Two things happened to open source software security in the same window, and together they change who is on the hook. The US federal effort that grew after the 2021 Log4j crisis has largely lapsed, with key personnel gone and the initiatives quiet. At the same time, the EU Cyber Resilience Act turned obligations for commercial users of open source software into law, with vulnerability and incident reporting requirements applying from September 2026. One backstop thinned. The other became a requirement with a date attached to it. If the plan was to wai...

The SBOM Just Became a Liability With a Date on It When a best practice becomes a product requirement, it stops being a security artifact and starts being a financial one. The question now is whether the document you are obligated to produce is true. The EU Cyber Resilience Act is moving the software bill of materials from a best practice to a product security requirement, with the law’s full application arriving in December 2027 . If your company ships software into the EU, the character of one of your obligations just changed. The software bill of materials you used to produce because it was responsible is becoming one you are legally required to produce because a regulator says so. That is not a procedural change. It moves the bill of materials off the security team’s task list and onto the company’s books, and most organizations have not adjusted to what that means. A best practice and a requirement are not the same liability Every CFO understands that an unmanaged liability is a ...

The EU CRA Doesn't Change What Good Open Source Governance Looks Like. It Just Makes the Accountability Visible. By Jacqueline Winter, CISO & CFO, ActiveState The Linux Foundation's 2026 CRA Awareness and Readiness Report documents where the industry stands. CFOs and CISOs who have already built a defensible governance posture are not reading it as a warning. They are reading it as context. Due diligence is not a concept invented for cybersecurity regulation. It has governed every material decision in finance, M&A, and vendor risk management for decades. The question is not whether open source software risk requires due diligence. The question is why most organizations accepted a lower standard for it than they would for any other contractual commitment. The EU Cyber Resilience Act (EU CRA) provides the answer: because no one required otherwise. That changes in December 2027. The Linux Foundation's 2026 CRA Awareness and Readiness Report surveys 843 respondents on...

Your Policy Was Complete. Then Your Company Adopted AI. By Jacqueline Winter, CISO & CFO, ActiveState Most organizations have a dependency governance policy. Somewhere inside it is an exception nobody signed off on. That exception is now material. At some point in the last few years, most security organizations made a governance decision about open source dependencies. They documented approved packages. They built a review process. They required SBOMs for production systems. The decision was real, the documentation was produced, and the policy looked complete. It is not complete. There is an exception built into nearly every one of these policies that nobody explicitly approved, because the policy was written before the exception existed. The exception is AI-suggested code. How the Gap Was Created Without Anyone Deciding When developers adopted AI coding assistants, the governance question was not raised at the executive level. It was not raised at the security team level. It was a...