This information is stored independently of the build, distribution and notification infrastructure. It cannot be blocked, because it is distributed peer to peer, and the current state cannot be hidden.

It is read from a smart contract on an ethereum network, which records each build under its rpm-md repository checksum. That same checksum is taken from the build's SBOM, which is what lets the two be matched up. Build Type is what the build was registered as: an rpmmd repository, a product medium or an oci_container. Every line below it is recorded against that type. Recency tells whether this build is the one the chain currently registers for its product and build type, shown green "yes" when it is and red "no" when a newer build has taken its place. It reads the contract's current_product_build() view directly. That view is keyed by product name and type together, so one product can hold a current build of each type at once: two builds of the same product both saying "yes" means they were registered under different types, not that the chain contradicts itself. Build Reproduced reflects the attestation an independent validator recorded after rebuilding the product.

Two different checksums are involved, and only one of them can be weak:

• The binary checksum — the rpm-md repository digest of the built repository. It is the key the build is registered and looked up under, taken from the SBOM, so it is a full digest by construction and is either found on the chain or not.
• The source reference — the git commit the product was built from, recorded alongside the registration. This is the one that can be weak, and it is what Registered Product Build reports on.

Registered Product Build shows: green when the registration carries a full SHA-256 source commit that agrees with the SBOM, yellow when it is registered but the source reference is too weak to verify against — a SHA-1 commit, a branch name, or the digest of the empty string used as a placeholder — which says nothing against the build, only that the source side cannot be checked, red when the source commit on the chain positively contradicts the one in the SBOM, and grey when not registered yet. It gates the rest of the box: the other three flags are all recorded against a registered build, so until one is registered they are left out rather than shown as three grey "not audited yet" rows.

Highest Known Security Issue is the severity the security team has reported against this build. A report names the build an issue was found in, and the contract carries it backwards over every earlier build of the same product, so a report filed today can change what an older build shows. The contract's four levels, least to most severe:

• low — minor issues, no workaround needed.
• moderate — issues with a workaround available.
• important — serious issues, update strongly recommended.
• critical — exploitable issues, the build must not be used.

None known means the chain was asked and reported nothing against this build — either no report exists for the product, or every report is about a build registered before this one, and a report never applies forwards. None known yet in grey is the different, weaker statement that no answer has been recorded. Only one severity is ever shown, because the chain records the highest level in effect rather than a count of issues. A badge in grey is a severity from neither vocabulary this page knows; it is shown rather than hidden, because it might be the worst one there is.

Last On-Chain Write is when the contract was last written to about this build — its registration, its attestation or a security report naming it. Nothing the contract stores carries a timestamp, so this is the time of the block the event was in, which is the chain's own clock rather than this server's. Not seen yet means no such write has been observed, which is not the same as none having happened: events are only dated from the point the monitor started watching, plus a bounded look back over recent history, so a build registered long before that can stay blank while being perfectly well registered.

The network and contract the box footer names are the ones these flags were read from. Following that link shows the same registry in a public block explorer, so the state shown here can be checked against the chain directly.

A grey marker means no answer has been recorded yet, which is not the same as a negative one: it also covers a build the contract has not been asked about yet, and a network that could not be reached.

The contract publishes the interface level it implements, and this page refuses to read a level it was not built for rather than risk misreading it. When the two disagree the monitor stops and a red warning appears here and on the page: the flags are then frozen at their last known state and nobody is checking them any more.