EU Cyber Resilience Act reporting, in force since September 11, depends on build-pipeline traceability

A report on an exploited component starts with a chain of lookups. According to The New Stack, a team first has to establish whether the component is present, then in which versions, under what configuration and in which customer-facing releases ^[5]. Each answer is a lookup. It only works if the build recorded the link between the shipped artifact and its source and dependencies when the artifact was made ^[4].

I think the SBOM point is the most useful one in the piece ^[6]. A bill of materials generated anywhere other than the build that produced the shipped binary has to be checked against that binary before anyone can report from it.

Configuration is the third lookup, and it connects to the article's first check. The article wants the safer configuration to be the initial one. It says a feature exposed by default can turn a configuration oversight into a vulnerability with a much wider blast radius ^[13]. A product that ships locked down has a shorter answer to the configuration question when a report is due.

I would adopt the maturity scale as written. It grades what a team can show, and a control nobody can show exists counts as absent ^[7]. The article sets "Standard" as the threshold. It says a control that depends on a single knowledgeable engineer, a spreadsheet or a pre-release scramble is not yet dependable at the speed of modern delivery ^[8]. The spreadsheet makes the list by name. The article states the principle in one sentence: "High-risk failures should not depend on someone noticing them; the delivery system should prevent them from progressing." ^[9]

The separate review path for security-sensitive changes also produces evidence for an incident. It leaves a trail of what changed, who reviewed it, what evidence supported the decision and which versions inherited the change ^[11]. That last field answers the versions question the report depends on ^[2].

Of the two dates, only the reporting one applies today ^[1][3]. The article does not quote the regulation on what a report must contain. It also says its questions do not substitute for legal advice or a complete CRA program ^[12]. So the legal duty in force now is the report itself. Pipeline traceability is the engineering precondition the article says a credible report needs. That list includes whether the release can be reproduced and whether the fix worked in the running product ^[2]. On the engineering, I agree with the article. A team that cannot map a finding to shipped artifacts cannot say which versions are affected ^[5].