Open Security | Thoughts & Commentary

Public accountability in cybersecurity comes down to one thing: security claims that people outside the organization can check. A patch policy, a breach notification, a procurement contract, a management attestation — each counts as accountable when four conditions hold. Somebody is named as responsible. A deadline is attached. An outsider can verify whether the deadline was met. And something actually happens when it wasn’t. Four conditions. It’s worth noticing how few security claims you’ve read this month meet even two of them.

Everything else in this piece — disclosure policies, transparency reports, statutory response clocks, reproducible builds — hangs off that structure. And the structure is why this matters to the people who read this blog, because almost none of you can audit code yourselves. A journalist staring down commercial spyware, a shop owner picking up supply-chain duties under the EU’s NIS2 Directive, an activist fighting a municipal surveillance purchase: all three depend on the same thing. Documents and deadlines they can hold up in public. That’s the difference between security as a vendor promise and security as a civic practice, and it’s the reason this site exists.

What public accountability means — and what it is not

Accountability is a structure, not a tone. CISA’s patch directives are accountable because they name who must act, set a clock, publish the list you check against, and carry consequences inside the agency when the clock runs out. Now take the sentence buyers see most often — “we take security seriously.” None of the four conditions. It isn’t a weaker version of accountability; it’s the opposite of it.

Plenty of what passes for assurance fails the same test. A SOC 2 Type II report usually travels under NDA, so the only people who can check it are already contractually close to the vendor. An ISO/IEC 27001 certificate is public, fine, but its whole meaning lives in the scope statement — and a scope like “data center operations in one country” says nothing about the mobile app your staff actually carry around. The fix isn’t to reject audits. The fix is to demand the parts a stranger can be shown.

Public accountability isn’t full disclosure, either. Coordinated vulnerability disclosure, laid out in ISO/IEC 29147, is the accountable standard precisely because it commits an organization to a named contact and timelines rather than to publishing exploitation details. And publishing your own network architecture, or the identities of your security staff, isn’t accountability — it’s a gift to attackers. The object of the exercise is a checkable process record, not a bigger attack surface.

The deadlines that are already running

Here’s my problem with how urgency usually gets manufactured in this field: it comes from threat actors, the scarier the better. Real urgency comes from calendars. Patch windows, reauthorization votes, procurement hearings, statutory response clocks — they run whether anyone watches or not. Public accountability is how the rest of us get to watch. These are the clocks that matter most to readers in the EU and North America right now.

Statutory response clocks in the EU

Under Article 33 of the GDPR, a data controller must notify its supervisory authority of a personal data breach within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the individuals concerned — and any delay has to come with reasons attached. Processors carry their own duty under Article 33(2): inform the controller “without undue delay.” This is a clock you can check from the outside. When a vendor tells you about an incident, ask when they became aware. The answer is a date. Dates can be compared. What Article 33 doesn’t cover: breaches involving no personal data, and the separate Article 34 duty toward affected individuals, which runs on “without undue delay” rather than a fixed hour count.

NIS2 turned the pressure up for essential and important entities. Article 23 sets a three-stage clock for significant incidents: an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report within one month. Article 20 attaches personal consequences — management bodies must approve the cybersecurity risk-management measures and oversee their implementation, they can be held liable for infringements, and they’re required to get training. Member states had until 17 October 2024 to transpose the directive, which means the operative text for your organization is your national law. Read that one, not a summary, because transposition details differ from country to country. The directive itself is the reference for what your national statute is supposed to contain.

One more date, for anyone selling products with digital elements in the EU: the Cyber Resilience Act (Regulation (EU) 2024/2847) schedules vulnerability and incident reporting duties — including a 24-hour report to ENISA for actively exploited vulnerabilities — from September 2026, with the main obligations applying from 11 December 2027. If you ship software or connected hardware, those dates belong in your product calendar now. Not in 2027.

Patch windows in the United States

In the US, CISA’s Binding Operational Directive 22-01 orders federal civilian agencies to remediate vulnerabilities on the Known Exploited Vulnerabilities (KEV) catalog on fixed clocks: two weeks for entries with a CVSS score of 9.0 or above, with longer fixed windows for lower scores. State the limit plainly, because it gets misread constantly: this directive binds agencies, not private companies. But the catalog is public, it’s published in machine-readable form, and nothing stops your organization from adopting it as a free, checkable patch priority list. Pair it with the Exploit Prediction Scoring System (EPSS), an open scoring model published by FIRST, and you have a triage method traceable to public documents instead of a vendor’s severity labels.

Reauthorization votes and procurement hearings

Some accountability moments are scheduled years in advance. The US Congress renewed Section 702 of FISA in April 2024 with a sunset in April 2026, and between now and that vote, every member of Congress holds an accountable position you can ask about in writing. Procurement is the other scheduled forum. In the EU, contract award notices are published in the Tenders Electronic Daily database, and EU institutions answer to Regulation (EC) No 1049/2001 on public access to documents. In the US, the Freedom of Information Act gives agencies 20 business days to respond, and state sunshine laws set their own clocks. When the European Parliament’s PEGA committee published its findings on spyware use against EU citizens in March 2023, it was these mechanisms — hearings, document requests, published records — that turned rumor into a public record. Not covered: national-security exemptions narrow every one of these paths, and a denial that cites an exemption is itself data about where oversight currently stops.

Why vendor promises fail and documents hold

A promise fails the four conditions. A document can pass them. The artifacts worth asking for, and checking, include:

• A disclosure policy aligned with ISO/IEC 29147, with a named contact and committed response timelines — made machine-findable through a security.txt file at the well-known location defined in RFC 9116.
• A dated public changelog or release feed, so anyone can verify whether a vendor met its own patch window.
• A software bill of materials (SBOM) in SPDX (standardized as ISO/IEC 5962) or CycloneDX (an OWASP standard) format, listing the components of the exact artifact you run. That lets you match public CVE records against your dependencies yourself, instead of waiting for a vendor’s email. US federal software suppliers have been expected to provide SBOMs since the May 2021 federal cybersecurity executive order pushed them into procurement, and the Cyber Resilience Act will make component transparency a product requirement in the EU.
• A transparency report with counts — government requests received, warrants challenged, canaries published — that can be compared year over year.
• Reproducible builds, the strongest form of public accountability in shipping software: anyone can rebuild the shipped binary from public source and compare the results. Signal publishes reproducible builds for its Android client, and the Debian project has run a multi-year reproducible-builds effort across its archive. You don’t have to perform the rebuild yourself. The point is that an independent party can, and that claim is checkable in a way no marketing sentence is.

None of this is free, and honest vendors say so. Changelogs tell attackers what changed. Disclosure timelines get abused by researchers chasing attention faster than fixes get written. The accountable middle path is coordinated disclosure and dated, delayed detail: publish the process record, not the exploitation recipe. I’ve sat on the buyer’s side of enough procurement calls to notice that the vendors who acknowledge this tradeoff openly are, more often than not, the ones whose other documents hold up too. Small sample, but it keeps proving itself.

What accountability looks like for three kinds of reader

Journalists: spyware is a procurement story

The Pegasus and Predator cases were not broken by intuition. They were broken by forensic work from teams like Citizen Lab, then carried by procurement records, parliamentary inquiries, and export-control decisions — including the US Commerce Department’s 2021 Entity List designation of NSO Group. When you report on surveillance technology, follow the paperwork. Which budget line. Which contract. Which oversight body signed. Which statutory clock was missed. Then apply the same standard to your own newsroom: publish a patch policy with dates and a named owner, and keep your architecture private. A newsroom that demands accountability from vendors while offering none of its own has no standing to ask.

Small-business owners: procurement is your hearing

You can’t audit a vendor’s code. You can audit their answers in writing before you sign, and in practice that’s the stronger position. Article 21(2)(d) of NIS2 names supply-chain security — including obligations spread across the chain of contracts — among the risk-management measures essential and important entities must take. Translation: your larger customers will soon send you the same questions you should be sending your suppliers. Keep a dated file of who you asked, what you asked, what they answered, and when. If something breaks two years from now, that file is your defense. It costs an afternoon to start.

Activists: records requests are security work

The surveillance tools used in your community were bought by a public body, from a company, under a signed contract. FOIA and state sunshine laws in the US, and Regulation (EC) No 1049/2001 for EU institutions, exist to surface those documents — and the federal FOIA clock runs 20 business days. Ask for contracts, invoices, purchase orders, training records, oversight correspondence. Expect exemptions, and count them. A pattern of denials under the same exemption is a finding you can publish, and it marks precisely where public oversight currently ends.

Five questions that turn a promise into a checkable claim

Use these in your next renewal negotiation or procurement email. Each one converts a vibe into a document.

1. Where is your vulnerability disclosure policy, and who answers reports? A policy aligned with ISO/IEC 29147 names a contact and commits to timelines; a security.txt file per RFC 9116 makes the contact machine-findable.
2. What is your patch service level, in writing, and where do you announce releases? “As soon as possible” is not a service level. A dated public changelog is checkable.
3. Can you provide an SBOM in SPDX or CycloneDX for the exact version we run? If the answer is no, ask what they can provide, and log the answer with a date.
4. Which incidents start a statutory clock on your side, and how fast will you tell us? A competent answer names Article 33(2) of the GDPR and the NIS2 early-warning clock without being prompted.
5. What exactly does your ISO 27001 certificate cover, and what can you share publicly? The scope statement is the entire meaning of the certificate. If the full report sits under NDA, ask which parts can be published — the answer is itself accountability data.

What this article does not cover

• This isn’t legal advice. For incident handling, talk to a lawyer and to your national data protection authority; the clocks above are statutory, and misreading one has consequences.
• National transpositions of NIS2 differ. Read your member state’s statute rather than relying on this summary.
• Certifications aren’t worthless. They’re evidence with a scope. The accountability gap lies in what can’t be shown publicly, not in the audits themselves.
• Secure development practice is its own discipline; NIST SP 800-218, the Secure Software Development Framework, is the primary reference, and it deserves its own article.
• Classified and national-security procurement sits largely outside every mechanism described here. That exemption zone is a live political question, not a settled one.

Your step for today: twenty minutes, one vendor

Pick one software vendor you currently pay. Spend ten minutes checking: does https://their-domain/.well-known/security.txt exist, does their site carry a disclosure policy with a named contact, and do their products show up in the public KEV catalog or in CVE records? Spend the next ten sending one email with questions 1 and 2 above, and log the send date. Whatever comes back — an answer, a deflection, silence — goes in your dated file. You’ve just produced the smallest unit of public accountability: a claim, a clock, and a record.

This article also opens a recurring column on this blog: The Paper Trail. Once a month, we’ll take one primary document — a directive, a scope statement, a disclosure policy, a records-request denial — and read it in public, line by line. The next installment reads a real SBOM and shows exactly what its fields do and don’t tell you. If you have a vendor policy you can’t parse, send it in; reader submissions set the queue.

Frequently asked questions

What is public accountability in cybersecurity?

It’s the practice of making security claims checkable from outside the organization making them. A claim is accountable when a named party is responsible, a deadline is attached, an outsider can verify whether the deadline was met, and a consequence follows when it wasn’t. Published patch policies, ISO/IEC 29147-aligned disclosure policies, statutory breach clocks, transparency reports, and reproducible builds are all examples.

What is the 72-hour rule?

Article 33 of the GDPR requires a data controller to notify its supervisory authority of a personal data breach within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals; delays must be justified with reasons. NIS2 runs a parallel clock for significant incidents at essential and important entities: a 24-hour early warning and a 72-hour incident notification.

How quickly must US federal agencies patch known exploited vulnerabilities?

Under CISA’s Binding Operational Directive 22-01, federal civilian agencies must remediate vulnerabilities on the Known Exploited Vulnerabilities catalog within fixed windows — two weeks for entries scored CVSS 9.0 or above, with longer fixed windows for lower scores. The directive doesn’t bind private organizations, but the catalog is public data any organization can adopt as a patch priority list.

What is an SBOM, and why does it create accountability?

A software bill of materials lists the components in a specific software artifact, in a standard format such as SPDX (ISO/IEC 5962) or CycloneDX. It lets a buyer match public CVE records against their own dependencies directly, instead of relying on the vendor’s severity claims or waiting for an email.

Can SOC 2 reports or ISO 27001 certificates be checked publicly?

Generally, no. SOC 2 reports are typically shared under NDA, and an ISO 27001 certificate only shows that a defined scope was audited — the scope statement, not the logo, carries the meaning. Ask vendors what portion of their evidence they can publish; the answer is itself accountability data.

Deadlines don’t wait, and neither should your file. Pick your vendor, send the email, start the record today.

…

…

Public accountability in cybersecurity means security claims that people outside the organization making them can actually check. A claim qualifies when it traces to a primary document, an open standard, or a procedure anyone can repeat. Security that cannot be checked still gets sold, signed, and budgeted on the strength of adjectives, and the people who carry the consequences — readers, sources, clients, employees — learn how thin the evidence was only after a breach. This article names the deadlines already written into law, shows where claims escape scrutiny, and leaves you with checks you can run today.

The audience is specific: journalists, activists, small-business owners, and non-technical professionals in the EU and North America. The civic calendar already supplies the pressure points — a procurement hearing, a reauthorization vote, a supervisory authority’s docket, a patch window that closes on a fixed date. This site treats open security as a civic practice: transparent, verifiable, and rights-based. Public accountability is the part of that practice anyone can operate, starting this afternoon.

What Public Accountability in Cybersecurity Means

Start with the definition. Public accountability in cybersecurity is the practice of making security claims verifiable by people outside the organization making them — security transparency with deadlines attached. Three tests decide whether a claim qualifies. Traceable: it points to a primary source anyone can read, such as Binding Operational Directive 22-01, Article 33 of the GDPR, or RFC 9116. Time-bound: it carries a deadline an outsider can watch, such as a 72-hour notification clock or a patch window. Repeatable: it survives a procedure a non-specialist can run, such as fetching a security.txt file or comparing a vendor’s patch record against a public catalog.

Give the failure mode its name: security by assertion, a claim resting on the speaker’s authority alone. Phrases like military-grade encryption, bank-level security, and enterprise-grade protection belong to that family. The open-standard counterexample is AES. FIPS 197, published by NIST in 2001, defines the algorithm in public, and its test vectors let anyone check an implementation. The accountable version of the sentence we use AES-256 names the mode, the key-management arrangement, and the date of the last audit. Everything else is atmosphere.

The Deadlines Already Exist — Few People Outside the Industry See Them

Urgency in security writing is usually manufactured. The urgency here is different: the clocks below are already running, they are written into public law, and most of the people they protect have never read a word of them.

Patch windows: the CISA Known Exploited Vulnerabilities Catalog

Binding Operational Directive 22-01, issued by CISA in November 2021, orders US federal civilian agencies to fix vulnerabilities on the Known Exploited Vulnerabilities Catalog within two weeks for entries added in 2021 and three weeks for entries added from 2022 onward. The catalog is public and updated continuously, which makes it a yardstick anyone can borrow: when a vulnerability affecting a product you depend on appears there, a clock the US government already considers reasonable has started.

What this does not cover: BOD 22-01 binds federal civilian agencies, not private companies, and the catalog lists vulnerabilities with confirmed exploitation, not every risk. Absence from the catalog is not evidence of safety.

Do today: search the catalog for the three products your organization depends on most. Two minutes, and you have a baseline.

Statutory clocks: NIS2 in the EU, GDPR for personal data

The NIS2 Directive (EU) 2022/2555 sets a three-stage clock for essential and important entities: an early warning to the national CSIRT within 24 hours of becoming aware of a serious incident, an incident notification within 72 hours, and a final report within one month. Member states had until 17 October 2024 to transpose it into national law. Most missed the deadline, and in November 2024 the European Commission opened infringement proceedings against twenty-three of them. The first public test of the law was whether governments could meet their own writing deadline, and the result is on the record.

GDPR runs alongside it. Article 33 requires a controller to notify its supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to the people concerned. Article 34 requires telling those people without undue delay when the risk is high. If an organization cannot say who owns that clock, when it started, or what it triggered, that is an answer too. Write the question down before the next incident, not after.

What this does not cover: health, finance, and energy carry their own sectoral clocks, and national transposition of NIS2 varies by member state — our NIS2 response-clock primer tracks the national versions. Verify the statute that applies to you before relying on any timeline here for a compliance decision.

Do today: bookmark your national CSIRT or data protection authority’s incident-reporting page and paste the URL into your incident plan. If no incident plan exists, that is your next deadline.

Where Security Claims Escape Scrutiny

Most security evidence is private, and the privacy runs one way: the buyer signs the contract, the seller keeps the evidence behind a non-disclosure agreement. Three escape routes deserve particular attention.

SOC 2. A Type II report can be genuine evidence that controls operated over a period of time, but the full report usually travels only under NDA, and buyers often see a one-page letter instead. The accountable questions are dull and answerable: What period does the report cover? Which Trust Services Criteria were tested? Which systems were in scope? A report that excludes the system holding your data is a report about someone else’s security.

ISO/IEC 27001. A certificate says a management system meets the standard within a stated scope. The scope statement is the entire document as far as accountability goes, and it is often narrower than the sales pitch. Ask for it in writing; a refusal is data.

Procurement is where the balance is slowly shifting. In the United States, OMB memo M-22-18 (September 2022) began requiring software producers selling to federal agencies to attest to secure development practices, with a common attestation form published by CISA in 2024. In the EU, the Cyber Resilience Act phases in vulnerability-handling and SBOM duties for products with digital elements across 2026 and 2027. Public buyers are turning security claims into signed, dated documents. Private buyers can copy the method now: put the attestation in the contract.

Journalists and researchers hold one more instrument: records law. FOIA in the United States and Regulation (EC) No 1049/2001 in the EU open agency files, with statutory response clocks — twenty business days under FOIA — and state and provincial laws reach municipal ones. Security contract annexes, audit findings, and incident timelines have all surfaced through records requests. The procedures are public; the volume of security-relevant requests remains strikingly low.

What this does not cover: none of this forces an organization to be secure. It forces the organization to be specific, and specificity is what outside scrutiny works on.

Four Checks You Can Run This Week

Each check below cites its primary source, states what the result does not prove, and takes under thirty minutes. No security team required.

1. Read a security.txt file (RFC 9116)

RFC 9116, published by the IETF in April 2022, defines a plain-text file organizations place at /.well-known/security.txt to tell researchers where vulnerability reports should go. Checking a service takes one browser tab: https://example.com/.well-known/security.txt. The file must carry a Contact field, and the Expires field tells you whether it is current. A missing file, an expired one, or a contact address that bounces is a documented, citable signal that inbound reports have no owner. Our step-by-step security.txt check walks through the details.

What this does not prove: a current file shows a policy exists, not that anyone reads the reports or fixes them.

Do today: check the three services behind your newsletter, your donor database, and your website. If one is missing, send the vendor a two-line email citing RFC 9116.

2. Score a vendor’s patch record against the KEV catalog

Pick one product you run and search the catalog for its vendor. Each entry carries the CVE identifier, the date it was added, and the due date under BOD 22-01; the vendor’s own advisories carry the fix date. Two columns and a subtraction give you a patch-latency number you can put in a procurement file and quote in a hearing.

What this does not prove: the catalog covers exploited vulnerabilities, not the vendor’s whole backlog, and it says nothing about flaws nobody has reported yet.

Do today: build the table for one product and set a quarterly reminder to update it.

3. Ask for the parts list: an SBOM in SPDX or CycloneDX

A software bill of materials names the components inside a product the way a food label names ingredients. SPDX is standardized as ISO/IEC 5962 and CycloneDX is an OWASP open standard, so the request is precise: your SBOM, in SPDX or CycloneDX format. The Cyber Resilience Act will make this a standing expectation for products with digital elements sold in the EU; nothing stops you from asking early.

What this does not prove: an SBOM names components; it does not grade them. The checking still has to happen.

Do today: add one sentence to your next purchase order or renewal email.

4. Test a reproducible-build claim

When a project says its builds are reproducible, independent parties can compile the published source and compare the results bit for bit. The Reproducible Builds project publishes the procedures, and several major Linux distributions run programs whose results anyone can compare. This is the strongest verifiable claim software can make: the release becomes checkable rather than believable.

What this does not prove: reproducibility says the binary matches the source, not that the source is good.

Do today: if you distribute software to sources or clients, read the project’s definition page and note whether your build process could support it.

If You Adopt One Framework, Adopt the Free One

In February 2024, NIST released version 2.0 of its Cybersecurity Framework and did something quiet but consequential: it added a sixth function, GOVERN, and put it first. Roles and responsibilities, policy, oversight, and supply-chain risk now open the most widely used open framework in the field, ahead of Identify, Protect, Detect, Respond, and Recover. For a small organization, GOVERN is mostly a writing exercise, and writing is what accountability is made of.

What this does not cover: CSF 2.0 is a framework, not a checklist. It organizes questions without answering them for your context, and it substitutes for none of the statutory duties above.

Do today: download the framework and the small-business quick-start guide from NIST’s CSF page, then write one GOVERN answer: who sets your patch deadlines, and for what date each month.

Build Accountability Into Your Own Operation

Accountability is not only something you demand from vendors; it is something you publish. A four-person newsroom can put most of this in place in an afternoon.

1. Publish a vulnerability disclosure policy with a security.txt file. Name a contact, set an expiry date you will actually renew, and keep the promise. Thirty minutes to set up.
2. Adopt a written patch calendar anchored to two public sources: your vendors’ advisories and the KEV catalog. The calendar is the accountability; the patching is the point.
3. Put three questions into your next contract, in writing: the ISO/IEC 27001 scope statement or the SOC 2 period and criteria, the vendor’s KEV patch record, and the URL of their security.txt. Written answers are quotable, and quotable is what turns a sales process into a record.
4. If you cover public institutions, file the records request. The security annex of a public contract is a document, documents have request procedures, and the response clocks bind the agency too.

What this does not cover: incident response, legal advice, and cyber insurance are separate disciplines. This list is the accountability layer, not the whole of security.

Frequently Asked Questions

What is public accountability in cybersecurity?

It is the practice of making security claims checkable by people outside the organization making them: every claim traceable to a primary document, an open standard, or a repeatable procedure, with public, measurable deadlines. The alternative is security by assertion.

What reporting deadlines already apply in the EU and North America?

GDPR Article 33 sets a 72-hour clock for notifying a supervisory authority once a controller becomes aware of a personal data breach. NIS2 sets a 24-hour early warning, a 72-hour incident notification, and a final report within one month for covered entities. In the United States, BOD 22-01 requires federal civilian agencies to patch KEV-listed vulnerabilities within two to three weeks. State, provincial, and sectoral rules add further clocks, so check the statutes where you operate.

What is security.txt, and how do I check one?

A standardized plain-text file defined in RFC 9116, published at /.well-known/security.txt, that tells researchers where to send vulnerability reports. Open the URL for the service in question and look for a Contact field and an unexpired Expires field. A missing or stale file is a citable finding, not an opinion.

How can a small business check a vendor’s security claims without a security team?

Ask for written evidence outsiders can read: the ISO/IEC 27001 scope statement, a SOC 2 report’s period and criteria, the vendor’s KEV patch record, an SBOM in SPDX or CycloneDX format, and a current security.txt. None of these requests requires a security team behind it.

Does an ISO 27001 certificate mean my data is protected?

No. The certificate attests that a management system meets the standard within a stated scope. Whether your data falls inside that scope is a separate question, answered by the scope statement rather than the seal.

Where should a journalist start with security accountability reporting?

With deadlines and documents. The KEV catalog turns patch latency into a number, statutory clocks turn response failures into dates, and records law opens the contracts and audits behind both. Start with one agency and one product.

The Step You Can Complete Today

Run the security.txt check on the three services your work depends on most. Three browser tabs, about three minutes. For every missing or expired file, send a two-line email citing RFC 9116 and asking when a current file will appear. That is the whole loop — one person, one check, one written question, one dated answer. Public accountability in cybersecurity is not a mood; it is that loop, repeated until vendors expect the question and agencies answer it on the record.

Kira Mikkonen edits open-security.org’s accountability coverage and has spent the past decade reading the primary documents behind other people’s security claims. Tips and corrections are welcome, especially the kind that arrive with a document attached.

Open source software runs on a simple promise: anyone can read the code, so anyone can check what it does. That promise sits at the heart of open security for democratic societies. A supply chain attack flips that promise against the people who rely on it. Instead of going after your laptop or your phone directly, an attacker compromises a library, a build tool, an update server, or a maintainer account you already trust. When you install or update software, the malicious code rides along inside something that looks completely legitimate. For journalists, activists, small-business owners, and non-technical professionals, this is not a thought experiment. It is a real threat to sources, client data, and the tools you use every day.

Supply chain attacks are not new, but they have become more frequent and more deliberate. The 2020 SolarWinds compromise showed how a single poisoned update could reach thousands of organizations, including government agencies. The 2021 Codecov breach exposed how a modified uploader script could leak credentials from software testing environments. The 2024 XZ Utils backdoor attempt showed how a determined attacker could spend years building trust in a widely used compression library before slipping in a hidden backdoor. In each case, the attack did not require breaking encryption or finding a zero-day in the target’s own code. It only required the target to keep trusting a supplier that had already been compromised.

This article explains how supply chain attacks exploit trust in open source, what makes them hard to spot, and what you can do to reduce your exposure without abandoning the open source tools you depend on. The point is not to make you afraid of open source. The point is to help you verify what you can, watch what you cannot, and make informed decisions about the software you use.

What Is a Supply Chain Attack?

A supply chain attack is any attack that compromises a product or service by targeting a less secure element in its supply network. In software, that usually means a third-party component: a code library, a package manager, a build script, a container image, a browser extension, or an update mechanism. The attacker does not need to break into your computer. They only need to break into one of the many suppliers you already trust.

Open source is especially attractive for supply chain attacks because it is built on a distributed network of maintainers, contributors, and automated build systems. Many open source projects are maintained by volunteers who have limited time and limited security resources. A single maintainer account can control a package that is downloaded millions of times per week. If that account is compromised, the attacker can publish a malicious version that looks exactly like a normal update.

There are several common types of supply chain attacks:

• Dependency confusion: An attacker publishes a malicious package with the same name as a private internal package, hoping that a build system will pull the public version instead of the private one.
• Typosquatting: An attacker publishes a package with a name that is one character away from a popular package, hoping that a developer will mistype the name during installation.
• Maintainer account takeover: An attacker steals the credentials of a package maintainer and publishes a malicious update under the maintainer’s name.
• Build system compromise: An attacker gains access to the servers that build and sign software releases, then injects malicious code into the final binaries.
• Update server compromise: An attacker modifies the files served by an update mechanism, so that users receive malicious code when they check for updates.

For the audience of this blog, the most important point is that none of these attacks require you to do anything wrong. You can download a legitimate package from a legitimate repository, verify its checksum, and still end up with malicious code if the package was already compromised before it reached you.

Why Open Source Trust Is Different

Closed-source software also has supply chains. A proprietary application may include third-party libraries, cloud services, and update mechanisms. But the user of closed-source software has no way to inspect the code, so they must trust the vendor’s word that the software is safe. Open source changes that relationship. The user can inspect the code, but in practice very few people do. The result is a paradox: open source is more transparent, but that transparency does not automatically produce verification.

Most open source users rely on the community to catch problems. That works well for popular projects with many active contributors. It works poorly for small projects with one maintainer and a handful of users. A supply chain attacker looks for the weak points in that community model: abandoned packages, overworked maintainers, automated build pipelines with weak access controls, and users who never check what they are installing.

For journalists and activists, the stakes are higher than for an average consumer. A compromised open source tool could expose a source’s identity, alter a document before publication, or silently record a conversation. A compromised password manager could leak every credential you have. A compromised VPN client could route your traffic through an attacker’s server. The trust you place in open source tools is not just about convenience. It is about the safety of the people who depend on your work.

How Attackers Build Trust Before They Break It

The XZ Utils case is the clearest recent example of how a supply chain attack can be built slowly and deliberately. Starting in 2021, an attacker using the name Jia Tan began contributing to the XZ Utils project, a compression library used by many Linux distributions. Over several years, Jia Tan submitted legitimate patches, built relationships with the maintainer, and eventually gained commit access. In 2024, Jia Tan inserted a backdoor into the build process that would have allowed remote code execution on systems using certain versions of the library. The backdoor was discovered only by accident, when a Microsoft engineer noticed that SSH logins were taking longer than expected.

This pattern matters because it shows that supply chain attackers are willing to invest years in building trust. They do not always rely on stolen credentials or a single malicious commit. They may become a trusted contributor, a helpful maintainer, or a reliable package publisher. By the time they act, their malicious code is hidden inside a project that the community has already accepted.

Other attacks are faster and less subtle. In 2018, the event-stream package on npm was compromised when its maintainer handed control to a new contributor who then added malicious code targeting a specific cryptocurrency wallet. The package had millions of weekly downloads, and the malicious code was active for weeks before it was discovered. In 2021, the ua-parser-js package was compromised when an attacker published malicious versions that attempted to install cryptocurrency miners and steal credentials. These attacks show that even a single compromised package can have a wide blast radius.

What Makes Supply Chain Attacks Hard to Detect

Supply chain attacks are hard to detect for several reasons. First, the malicious code is often hidden inside a legitimate package, so it looks like a normal update. Second, the code may be designed to activate only under specific conditions, such as a particular operating system, a particular build environment, or a particular target. Third, the attack may be spread across multiple components, so no single file looks suspicious on its own. Fourth, the tools that developers use to verify packages, such as checksums and signatures, only verify that the package came from the expected source. They do not verify that the source itself is trustworthy.

For non-technical users, the problem is even harder. You may not know which open source packages are inside the applications you use. You may not know how to check a package’s history, its maintainers, or its build process. You may not have the time to audit every update. The result is that supply chain attacks often go unnoticed until someone with deep technical knowledge happens to spot an anomaly.

This is not a reason to give up on open source. It is a reason to be more deliberate about which open source tools you trust, how you update them, and how you monitor them for changes.

Practical Steps for Journalists, Activists, and Small-Business Owners

You do not need to become a security researcher to reduce your exposure to supply chain attacks. You need a few consistent habits and a willingness to ask questions about the software you use.

1. Reduce the Number of Tools You Depend On

Every additional tool is another supply chain. If you use a password manager, a VPN, an encrypted messaging app, a document editor, a cloud storage service, and a browser extension, you are trusting at least six different supply chains. Some of those tools may be open source, some may be closed source, and some may be a mix. The fewer tools you use, the fewer opportunities an attacker has to compromise your workflow.

This does not mean you should use one tool for everything. It means you should be intentional about which tools you choose and avoid adding new tools without a clear reason. For example, if you already use a password manager that works well, do not switch to a new one just because it has a new feature. Every switch introduces a new supply chain and a new set of risks.

2. Prefer Tools with a Strong Maintenance Record

Open source projects with many active contributors, regular security audits, and a clear process for reporting vulnerabilities are generally safer than projects with one maintainer and no documentation. Look for projects that have been around for several years, that publish security advisories, and that respond quickly to reported issues. A project that has survived multiple security incidents and improved its practices is often a better choice than a new project with no track record.

For example, the Tor Project, Signal, and the Electronic Frontier Foundation’s tools have all been through security reviews and have public processes for handling vulnerabilities. That does not make them immune to supply chain attacks, but it does mean that an attack is more likely to be detected and disclosed quickly.

3. Update Carefully, Not Automatically

Automatic updates are convenient, but they also mean that a compromised update can reach you before anyone has had time to notice. For high-risk users, it is often better to wait a few days after an update is released before installing it. This gives the community time to spot problems and publish warnings. It also gives you time to check whether the update has been discussed in security forums or on the project’s mailing list.

This does not mean you should never update. Outdated software is a security risk of its own. It means you should update on a schedule that gives you time to verify, rather than updating the moment a new version appears.

4. Verify What You Can

If you are comfortable with basic command-line tools, you can verify the checksum of a downloaded file against the checksum published by the project. This confirms that the file you downloaded is the same file the project published. It does not confirm that the project itself is trustworthy, but it does protect you against a compromised download server or a man-in-the-middle attack.

For packages installed through a package manager, you can check the package’s version history, its maintainers, and its dependencies. Many package managers now include tools for checking package integrity and for detecting known vulnerabilities. For example, npm includes npm audit, and Python’s pip includes pip-audit. These tools compare your installed packages against known vulnerability databases and can alert you to packages that have been flagged.

5. Separate High-Risk and Low-Risk Activities

If you are a journalist working with sensitive sources, do not use the same device for social media, personal email, and source communication. A supply chain attack that compromises a browser extension or a social media app could then reach your source files. Use a dedicated device or a dedicated virtual machine for high-risk work, and keep the software on that device to a minimum. This is sometimes called compartmentalization, and it is one of the most effective defenses against supply chain attacks because it limits the blast radius.

For small-business owners, the same principle applies. Do not use the same computer for online banking, customer data, and general web browsing. If a compromised browser extension steals your banking credentials, the damage is contained if your customer data is on a separate device.

6. Monitor for Unexpected Behavior

Supply chain attacks often leave traces. A program may start using more CPU or memory than usual. A login may take longer than expected. A network connection may appear to a server you do not recognize. These small anomalies are easy to ignore, but they can be the first sign of a compromise. If you notice something unusual, do not dismiss it. Check the project’s issue tracker, search for recent security advisories, and consider whether the behavior could be related to a recent update.

For non-technical users, this is the hardest step. You may not know what normal behavior looks like. But you can still notice when a program suddenly asks for a new permission, when a browser extension changes its behavior, or when a device starts running slowly for no obvious reason. These are signals worth investigating.

What the Open Source Community Is Doing

The open source community is not ignoring supply chain attacks. Several initiatives are working to make the ecosystem more resistant to compromise.

The Open Source Security Foundation (OpenSSF) is a cross-industry collaboration that funds security audits, develops best practices, and maintains tools like the Scorecard, which evaluates open source projects on criteria such as code review, branch protection, and dependency updates. The SLSA framework (Supply-chain Levels for Software Artifacts) defines a set of increasing security requirements for build systems, so that users can verify that a package was built from the source code it claims to be built from. The Sigstore project provides free tools for signing and verifying software artifacts, making it easier for maintainers to prove that a package came from them and not from an attacker.

These tools are not a complete solution. They require maintainers to adopt them, and they require users to check the results. But they are a meaningful improvement over the previous state, where a package’s trustworthiness was often based on nothing more than its download count and its age.

For the audience of this blog, the practical takeaway is that you can look for projects that use these tools. A project that publishes a SLSA provenance, signs its releases with Sigstore, and has a good OpenSSF Scorecard is making a public commitment to supply chain security. That commitment is not a guarantee, but it is a signal that the maintainers take the problem seriously.

What to Do If You Suspect a Compromise

If you suspect that a tool you use has been compromised, act quickly but calmly. The first step is to stop using the tool. Disconnect the affected device from the network if possible. Do not log into any accounts from that device until you have assessed the situation.

The second step is to check the project’s official channels. Look for a security advisory, a mailing list post, or a GitHub issue that describes the problem. If the project has a security contact, report what you observed. If the project does not have a security contact, consider reporting the issue to a relevant CERT or to the package repository where the tool is hosted.

The third step is to change any credentials that may have been exposed. If the compromised tool was a password manager, assume that all passwords stored in it are compromised and change them from a clean device. If the compromised tool was a VPN or a messaging app, assume that your traffic or your messages may have been intercepted and adjust your behavior accordingly.

Finally, document what happened. Write down what you observed, when you observed it, and what you did in response. This documentation will help you if you need to report the incident to an employer, a client, or a law enforcement agency. It will also help you spot patterns if the same problem occurs again.

Frequently Asked Questions

How do I know if an open source tool has been compromised?

You may not know immediately. Supply chain attacks are designed to be quiet. But you can watch for signs: unexpected permission requests, unusual network connections, slower performance, or a sudden change in behavior after an update. You can also check the project’s security advisories, issue tracker, and mailing list for reports of compromise. If you are comfortable with command-line tools, you can use package audit tools to check for known vulnerabilities in your installed packages.

Is open source more vulnerable to supply chain attacks than closed source?

Open source is not inherently more vulnerable, but it is attacked more often because it is widely used and because its supply chain is more visible. Closed-source software also has supply chains, but users cannot inspect them, so attacks may go unnoticed for longer. The advantage of open source is that when an attack is discovered, the community can analyze the code, publish a fix, and warn users. The disadvantage is that the same transparency that enables verification also enables attackers to study the code and find weak points.

What is the single most important thing I can do to protect myself?

Reduce the number of tools you depend on and update them carefully. Every tool is a supply chain, and every update is a chance for an attacker to slip in. Use fewer tools, choose tools with a strong maintenance record, wait a few days before installing updates, and separate high-risk activities from low-risk activities. These habits will not make you immune, but they will make you a much harder target.

Can I still trust open source software for sensitive work?

Yes, but trust should be based on evidence, not on the fact that the code is open. Look for projects that have been audited, that publish security advisories, that sign their releases, and that have a clear process for reporting vulnerabilities. Use tools like OpenSSF Scorecard and Sigstore to check a project’s supply chain practices. And remember that no tool is perfectly safe. The goal is to reduce risk, not to eliminate it.

Next Steps for This Blog

This article is the first in a series on open source supply chain security. Future articles will cover how to read a software bill of materials, how to evaluate a project’s maintainer history, and how to set up a minimal verification workflow for non-technical users. If you have questions about a specific tool or a specific incident, send them in. The goal of this blog is to build a practical, verifiable guide to open security for people who cannot rely on closed-source or vendor-controlled solutions.