Changelog: Ready to Report

The Cyber Resilience Act’s Article 14 reporting obligations apply from September 11, and they cover products already on the market, not only new ones. Once a manufacturer becomes aware of an actively exploited vulnerability, an early warning is due within 24 hours and a full notification within 72, naming the corrective measures taken. That is not much time to go looking for the reasoning behind a decision somebody made months earlier, which is roughly where August went: manual compliance evidence now requires a written justification, every piece of evidence is reviewed on its own terms, and an override’s status is a decision an administrator records rather than one Chainloop infers.

Every Piece of Evidence Carries a Justification

Not every requirement can be satisfied by a pipeline. Some proof lives in a signed contract, a training record, or a screenshot from a system Chainloop does not reach. Manual evidence has always covered those cases, and until this month a bare attachment or a ticked checkbox was enough. Six months later nobody could say what that checkbox meant. The evidence existed. The reasoning did not.

Manual evidence submissions and requirement overrides now require a justification of at least 10 characters, enforced on submission rather than only in the form, so an API client cannot route around it either. Every manual claim in your compliance posture carries the argument that was made for it, in the words of the person who made it.

To be clear about what this is not: Chainloop does not file your CRA report. The Single Reporting Platform has no API at launch, so that submission is a web form a person fills in. And a ten character minimum will not stop someone from typing “approved by security” and moving on. What the requirement does is turn an empty justification into a choice somebody made, visible to the next reader, rather than a field that was never there to begin with.

Require evidence attachment. A new organization setting, off by default, that demands a file or a link on top of the justification. Turn it on and the forms keep submit disabled until one is provided. It stays off by default because plenty of requirements are legitimately satisfied by a written statement.

Reject a submission, keep the record. Administrators can now reject a plain manual proof with a mandatory reason, matching the override flow. The submission is preserved with a Rejected badge and its reason, and counts as not submitted, so an approved sibling still satisfies the check. Rejected evidence is a data point, not garbage.

Authors can withdraw their own work. Previously only while a submission was still pending review. Authors can now delete their own evidence at any review status, and the requirement is re-evaluated when they do.

Every Item Gets Its Own Verdict

An override often collects several pieces of evidence from several people. Reviewing it as a single unit meant one questionable attachment forced a verdict on everything next to it, and rejecting the override discarded what had already been submitted.

Every evidence item now carries its own approval lifecycle. Evidence attached by someone with write access on the target lands approved. Evidence from a project or product viewer arrives pending review. Administrators can approve, reject with a mandatory reason, or reset each item individually, and rejected evidence is kept with its reason shown on the badge instead of thrown away. The behavior is turned on through an organization setting, alongside the existing one that forces approvals.

The Override Status Is Somebody’s Decision

When we shipped evidence-level approval on August 14, an override’s status was derived from its items. Any rejected item failed it, anything pending sent it back to review, fully approved evidence passed it. It was tidy, and it was wrong. An administrator who accepts an override despite one rejected attachment is making a judgment call, and the system was quietly overwriting it. An override is also exactly the kind of decision a regulator asks about later, so the record needs to show what a person concluded, not what a rule computed.

That derivation is gone. The status is a decision an administrator makes explicitly, and approving, rejecting or resetting an individual evidence item never changes it. Adding or removing evidence sends the override back to In Review only when the review workflow actually applies to the person doing it, and the history attributes those automatic resets to Chainloop rather than to the user.

Accepting an override now asks for a justification just as rejecting does. The override header shows Justification under every status, and each decision stays recorded in the override history next to the evidence approvals it accompanied.

Also in August

Three releases went out last month and the reporting theme only covers part of them. A few others worth knowing about:

Repositories that lose access now tell you. A linked repository that gets removed, renamed or transferred used to leave every dispatched scan failing at credential resolution with nobody told why. Chainloop now tracks reachability, raises an incident naming the repository, and stops dispatching scans that could only fail.

Every GitHub App installation is its own connection. One broken installation no longer makes the whole integration report validation errors, and fixing it no longer means disconnecting every account. Existing organizations were split automatically.

New findings can open Linear tickets. Product notifications can route new findings into Linear, one ticket per finding, idempotent per finding and team so a retry never duplicates.

Open remediation pull requests at a glance. A project version’s Security tab now lists every assessment whose automated remediation is waiting on a pull request.

The pull request behind a validation run. A PR validation run records the pull request that triggered it and links back to the provider.

Choose which workflow templates your teams can use. A new organization setting decides whether teams are offered the templates Chainloop ships, your own, both, or none.

Full changelog at docs.chainloop.dev/changelog.

• Request a demo: chainloop.dev/book-a-demo
• Documentation: docs.chainloop.dev
• Open source: github.com/chainloop-dev/chainloop
• Follow us on LinkedIn