HARBOR DESK / 06 / PRACTICE GUIDE

DevSecOps and the software supply chain

Show which code was checked, by which tool and through which artifact, rather than relying on a green pipeline. SAST, DAST, SCA and SBOM produce different evidence.

Download guide and workpapers

Original AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.

CODE REVIEW DESK

See the decision through the test.

Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.

Green but unreviewed / Weak code

Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.

s=>s.jobGreen

A green job may skip scanning or leave findings unreviewed. The model requires execution, same-revision and review evidence; it does not run scanners.

Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.

01 / EXPLANATION

The role of scanning tools

SAST examines possible flows in source or compiled representations, DAST observes a running system, and SCA examines dependency risks. Secret scanning looks for credential patterns. None fully proves business logic. Record tool version, rules, exclusions and actual exit status; a job swallowing failure with || true may be green while its control failed.

02 / EXPLANATION

Dependencies and SBOM

Checking direct packages alone misses transitive dependencies. Review lockfile changes and verify package origin, maintainer and license policy. An SBOM is an inventory, not a security approval: without an artifact digest its described release is ambiguous. Assess a CVE match against actual use, reachability and remediation options rather than silently suppressing it.

03 / EXPLANATION

Release what was tested

A mutable release tag does not guarantee identical contents. Bind artifact digest, verified provenance, test results and approval to the same content. Do not expose production secrets to untrusted PR jobs; restrict runner identity and privileges per job. This workshop does not modify organizational CI. Run the fixture locally and adapt it through a controlled pipeline change.

04 / EXPLANATION

Release record example: one artifact

For a Harbor Desk change, bind source revision, test command and outcomes in one record. When an organizational pipeline builds a package, capture its digest and require matching SBOM and provenance. If the tested package is rebuilt, do not assume old outcomes apply to the new bytes: dependencies or build environments can differ even with identical source. Stop the decision gate when a security job did not run, or use the authorized exception process. The downloadable model demonstrates the effect of evidence fields; it does not verify provenance signatures or generate an SBOM. Obtain those outputs from the actual pipeline.

Build the evidence yourself.

Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.

Scope and trust boundariesMarkdown · ENTest plan and expected resultsMarkdown · ENFinding and retest recordMarkdown · ENRelease decision and evidence traceMarkdown · EN
Full guide with code, outputs and reasoning ↓

Primary references

Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.