A widely used crate holds an OpenSSF passing badge, yet its two maintainers share a single publish account. What does the badge assert, and what is it silent about?
answer
- process claim, not artifact claim
- nobody checks the answers
- no criterion asks who can publish
- shared account erases non-repudiation
- crypto criteria cover the code, not the token
basics
~10 sThe badge asserts the project's own account of its process: license, reporting channels, tests, static analysis, patch timeliness. It is silent on credential custody and on whether a published artifact matches the reviewed source.
solid answer
~50 sA passing badge is a **self-asserted claim about process**, made by the maintainers and published with justifications. It says the project has a license, a public repository, a documented private vulnerability-reporting path, tests, static analysis, and no publicly known unpatched medium-or-higher vulnerability older than 60 days at the time of answering. It says nothing about **who holds the keys**. A shared publish account means one credential compromise yields a release the ecosystem trusts, and it destroys non-repudiation: after a bad release, nobody can tell which maintainer pushed it. The badge's cryptography criteria cover how the *software* uses cryptography, not how the *team* stores publishing credentials. So treat the badge as a prior on maintainer engagement, then apply controls you verify yourself at the artifact: pin to a content digest, and verify signatures or provenance where the project publishes them.
go deeper
Know that the badge is filled in by the project itself and describes how the project is run, so it cannot tell you anything about who is allowed to publish a release.
Explain the scope line: the badge's criteria describe development practice and the software's own use of cryptography, while credential custody and artifact integrity are simply not among them.
Show the operational move — keep the badge as a signal of engagement, then pin by content hash, verify any signature or provenance at pull time, and name the shared-credential risk in writing rather than assuming it was covered.
Own the framing for the organisation: a self-asserted upstream claim can inform a decision but must never be the evidence of record, and your policy should state which assurances you verify yourself.
## Separate the three claims The fastest way to answer this is to keep three different claims apart, because the badge only makes the first one: | Claim | What answers it | |---|---| | How is this project developed? | The badge entry — self-asserted, project-level | | What is inside this artifact? | An inventory of its components | | How did this artifact come to be, and who vouches for it? | Build provenance and a signature over the artifact | A passing badge is firmly in row one. It is the maintainers' own written account of their practices, published with justifications and reviewed by nobody. ## What the badge does assert here For this crate, a passing badge is a real, non-zero signal. It tells you the project has: an OSI-approved license; a public repository with versioning and release notes; a documented, **private** channel for vulnerability reports and some evidence that reports get answered; a working build and an automated test suite with a policy of adding tests; enabled warnings; static analysis with exploitable findings fixed; sound use of cryptography inside the code with no hardcoded credentials; delivery protected against tampering in transit; and, as of the day the entry was filled in, no publicly known unpatched vulnerability of medium or higher severity older than 60 days. That is genuinely more than most transitive dependencies can say, and the fact that someone bothered is itself evidence of engagement. Do not throw the signal away — just do not overread it. ## What it is silent about **Credential custody.** No criterion asks who can publish, how many people hold that ability, whether the credential is shared, where it is stored, or what happens when a maintainer leaves. A single shared publish account is the concrete failure this scenario is built around, and it has two distinct consequences: 1. **Blast radius.** One credential is the whole publishing pipeline. Compromise of either maintainer's laptop — or of the shared secret in any place it has been copied to — yields a release that every downstream consumer will install as a normal upgrade, from an identity the ecosystem already trusts. Nothing in the badge would change, and nothing in the badge would notice. 2. **Loss of non-repudiation.** If a malicious version does appear, the audit trail says only that *the account* published it. Neither maintainer can prove they did not, and you cannot scope the incident to one person's compromised machine. The asset destroyed here is audit truth, and it is destroyed before any attacker shows up — the shared account destroyed it the day it was created. **The artifact.** The badge describes the project. It does not tell you that the package on the registry was built from the source you can read, that the tag you are pinning to is the tree that was reviewed, or that the published file has not been replaced. Those are questions about the artifact and its origin, and they need artifact-level evidence. **Currency.** The entry has a last-updated date and nothing expires it. "No known unpatched medium-or-higher vulnerabilities older than 60 days" was a claim about the day it was answered, not a live scan running today. A badge earned during an active period can sit unchanged through years of drift. **Scope confusion to name explicitly.** Maintainers sometimes point at the badge's cryptography criteria as if they covered this. They do not. Those criteria are about the software's own use of cryptography — algorithm choice, absence of hardcoded credentials, protected delivery. How the humans store the token that lets them publish is simply not in scope for any level of the badge. ## What you actually do about it As a consumer you cannot fix upstream's account hygiene, so move your controls to where you have leverage: - **Pin by content, not by name.** Resolve to a specific version and record its content hash, so an unexpected republish under the same name fails rather than silently upgrading you. - **Verify what upstream does publish.** If the project signs releases or publishes provenance tying an artifact to a build from a named source revision, verify it at the point you pull, not once during evaluation. Signing that nobody verifies changes nothing. - **Read the entry, not the badge.** Which criteria were marked N/A, what the release-process justification actually says, when the entry was last touched. That prose often reveals the shared-account situation without anyone naming it. - **Record the gap.** If you depend on this crate heavily, the risk register entry should say "upstream publishing is a single shared credential; compensated by pinned digests and review of upgrades" — a statement of what you verified, not a badge image pasted in as evidence. The interview answer in one line: **a badge is upstream's description of its process; artifact integrity and credential custody are neither described nor implied, so verify those yourself.**
- The maintainers say the badge's cryptography criteria already cover this. Are they right?No, and it is a scope confusion worth correcting. Those criteria concern how the software uses cryptography — algorithm choice, protected delivery, no hardcoded credentials in the code. How the maintainers store the credential that lets them publish a release is outside every level of the badge.
- What would actually give you assurance about who published a given release?Evidence bound to the artifact rather than to the project: a signature you verify at the point of consumption, and provenance stating which build produced this artifact from which source revision. Note that a shared account still collapses accountability to one identity, so it weakens attribution even when signatures verify.
- Does a passing badge mean the project has no known vulnerabilities right now?No. The relevant criterion is narrower and time-boxed: no publicly known unpatched vulnerability of medium or higher severity older than 60 days, asserted when the entry was filled in. It is a self-reported snapshot, not a live scan, and nothing forces the entry to be refreshed.
- Would you drop the dependency over the shared account?Usually not on that alone — you would raise the cost of a bad release reaching you. Pin to a content digest, review upgrade diffs for a heavily used dependency, verify any signature or provenance upstream does publish, and record the residual risk explicitly rather than treating the badge as having covered it.
saying these in an interview costs you the question
- Treats the badge as evidence that releases are trustworthy
- Assumes crypto criteria cover maintainer credential storage
- Says a passing badge means no known vulnerabilities today
- Confuses a process claim with artifact integrity
- Believes someone verified the entry before it published