An SBOM Is a Starting Point: Build Evidence Around a Software Release

A dependency inventory becomes useful when someone can act on it. If a security notice arrives on Monday, a team needs to identify the affected release, understand whether the component is used, choose a response and verify the replacement. A file listing packages helps with the first investigation. The surrounding engineering determines whether that investigation ends in a safe deployment or another unresolved ticket.

On October 22, ENISA published its Technical Advisory for Software Bill of Materials. Its stated scope includes implementation architecture, lifecycle data flows and threats to the SBOM ecosystem, with particular attention to smaller organizations and software stewards. That is a useful prompt for career preparation: build a small, inspectable release workflow around an inventory. The exercise below is our proposed learning project, with synthetic examples rather than measured employer results.

Begin with a release somebody could identify

Choose a small application you own and a repeatable build. A service with a health endpoint, a database adapter and a few dependencies is sufficient. Record the source revision, the build command, the runtime version and a digest of the resulting artifact. Keep secrets out of the example. The goal is to make one release easy for another engineer to find and inspect without relying on your memory.

Give the application a deliberately modest purpose, such as storing fictional reading lists. A reviewer should understand its data model in minutes. Complicated business logic can hide the supply-chain decisions you want to demonstrate. Include one direct dependency and at least one transitive dependency in your investigation, and explain the difference using the actual resolved dependency graph. State which package manager and inventory tool produced the evidence.

Ask which inventory you have generated

A source repository, a resolved dependency graph and a deployed container can contain different sets of components. Development tools may never reach the runtime image. A build step can fetch an extra resource. An operating-system package can enter through a base image even when it is absent from an application lockfile. For this exercise, write down exactly which boundary your inventory covers and which boundaries remain outside it.

Do not silently combine inventories from different releases. Store the inventory beside the artifact identity and retain the generator version and invocation. If you generate both an application inventory and a container inventory, give them distinct names and explain their relationship. A reviewer should be able to answer whether a component was found in source inputs, in the built image, or in both, without guessing what the filename means.

Separate composition from the build story

An inventory describes components. Build provenance adds information about how an artifact was produced. The SLSA provenance specification describes verifiable information for tracing artifacts through their production; its build and source tracks address different parts of that history. These records can complement each other. Neither a familiar filename nor a successful upload proves that a release satisfies every security requirement.

In the project, make the relationship concrete with a release record containing pointers to the artifact, inventory and build evidence. Then deliberately attach the previous release's inventory to a new artifact in an isolated test. Your verification should reject the mismatch. This is a proposed negative test, not a claim of formal SLSA certification. It demonstrates that your workflow checks the relationship it advertises instead of merely collecting documents.

Build a response exercise around one component

Create a fictional advisory for a component in your sample application. Label it clearly as fictional so that it cannot be mistaken for a real vulnerability report. Give it an affected version condition and a relevant execution path. Then walk through the questions an operator would need to answer: which release includes that component, where that release is deployed in the exercise, and which behavior might be affected?

Keep the conclusions narrow. Finding a component is evidence of presence, not proof that a vulnerable function is reachable. Failing to find a component in an incomplete inventory is also weak evidence of absence. Write an investigation note that distinguishes what you observed from what you inferred and what remains unknown. An explicit uncertainty can lead to a follow-up test; an unjustified assurance can prematurely close the investigation.

Make the decision visible

Use a short decision record rather than a large dashboard. For each case, record an owner, the evidence inspected, the response chosen and the condition that would reopen the decision. Possible responses in this synthetic exercise include upgrading a dependency, removing an unused feature, temporarily restricting a path, or investigating further. A deferred decision needs a review date and a reason that another engineer can challenge.

Avoid presenting a scanner's severity label as the entire decision. The exercise should show how a technical finding reaches an accountable person. A dependency update can have compatibility consequences, and a temporary mitigation can stop working after configuration changes. Explain how you would discover those changes. This is particularly useful for candidates whose experience sits between development, security and operations: the handoff itself can be a substantial piece of engineering work.

Repair the release and preserve the comparison

Build a replacement from a controlled source revision. Regenerate the inventory and compare the relevant component identities. Run the application's ordinary behavior checks as well as the test associated with the fictional advisory. Keep the original artifact and records available inside the exercise so a reviewer can inspect the transition. Replacing a file in place would erase part of the argument you are trying to make.

Document an unsuccessful repair too. For example, a direct dependency may be updated while another path still introduces the old transitive component. A useful report explains how the second path was discovered and what changed next. Do not insert a vulnerable public service on the internet to make the demonstration realistic. Local, disposable environments with synthetic data are enough to show the reasoning and keep the scope manageable.

Test the evidence pipeline itself

Treat the inventory and its metadata as inputs that can be incomplete, malformed or unrelated to the release. Proposed tests include a missing artifact digest, an unsupported document version, a component with an ambiguous identity, and a truncated inventory. Decide which cases should block a release and which should create a visible investigation task. A test should explain the policy decision it protects.

There is a useful distinction between collecting a document and trusting its contents. A checksum can help detect an accidental change relative to a known value; it does not by itself establish who created the value. Describe the trust boundary for your example and the controls you actually implemented. If signatures or attestations are outside the project, name that limit instead of decorating the README with an unsupported security level.

Keep the project affordable and reviewable

You do not need a paid platform or a fleet of services. Use a local runner or an existing free development environment, a small repository and a bounded set of artifacts. Keep generated files out of source review when they overwhelm the meaningful changes, but provide a repeatable command and a compact checked-in example. Record any tool limitations that affect the interpretation of the output.

Budget the reviewer's time as carefully as the build time. Start the README with the fictional incident, the release identities and the final result. Put the detailed inventory and logs behind links. Include enough evidence to reproduce one conclusion without asking somebody to inspect thousands of package entries. A small project with a clear failure and a verified repair is easier to discuss than a collection of unexplained badges.

Translate the work into role-specific evidence

For a backend role, emphasize how you isolated the affected execution path and checked behavior after an update. For a security role, emphasize the trust boundaries, triage decision and negative tests. For a platform role, show how the release contract makes evidence available to other teams. For QA, explain the regression scenario, fixtures and acceptance conditions. These are different perspectives on the same controlled experiment.

Use ApplyDjinn's vacancy search to examine relevant responsibilities, then verify the employer's original description. A mention of SBOM, dependency scanning or supply-chain security is a research lead. It does not establish that every engineer at that company owns the same workflow. Save the specific requirement you intend to address, and connect it to the part of the project you personally designed or tested.

A concise interview walkthrough

Prepare to explain the project in three passes. First, identify the release and the fictional problem. Second, show the evidence that changed your decision. Third, show how the repaired release was verified and what your controls still do not establish. Keep a longer technical appendix available for questions about component identity, build isolation or trust. The short explanation should remain understandable without those details.

An honest résumé statement could describe implementing a reproducible inventory-to-release check and testing a dependency repair in a local service. Add numbers only when they come from your own recorded run and their units are clear. Do not convert a practice exercise into an enterprise security claim. The credible achievement is the decision process you can reproduce, including the failure cases you discovered along the way.

What to finish this week

At the end of the exercise, another person should be able to locate two release artifacts, connect each to its inventory, reproduce one mismatch rejection and follow one repair decision. They should also know what was synthetic and what was actually tested. That set of evidence is a practical foundation for a conversation about software supply chains, without requiring a huge repository or an unsupported claim about market demand.

If you already have a portfolio service, improve its release evidence instead of starting from zero. If you are new to the area, begin with the artifact identity and one dependency. Expand only when each additional control answers a question the existing project cannot answer. The result should make the software's history easier to inspect and the next engineering decision easier to justify.

Sources and scope

• ENISA: Technical Advisory for Software Bill of Materials, October 22, 2026. The publication announcement establishes the advisory's date, intended audience and lifecycle scope.
• SLSA 1.2: Provenance. Definitions and the distinction between build and source provenance; use the specification matching your implementation.
• The application, advisory, response workflow and tests above are original ApplyDjinn learning proposals. They are not a report of a production incident, a compliance assessment or a measurement of hiring demand. Diagrams illustrate the proposed workflow and contain no employer data.