LEARN. PRACTICE. GROW.1. Define what needs analysis
In a fictional funds API release, the team requires code, dependency, secret and container-image analysis. Start by linking each requirement to an artifact and an inspectable execution. Code can be identified by commit; the image by the digest that will be delivered. A default-branch scan does not automatically represent an unmerged PR head. A dependency inventory does not replace code analysis either. Build a small matrix covering analysis type, candidate, tool, configuration, result and decision. If a field is missing, record the gap before summarizing status. The committee needs to understand which risks were assessed and which depend on additional evidence. A high count of green checks cannot answer that question without information about their respective scope.
2. Preserve SARIF result identity
A monorepo may analyze payments and reporting separately using the same tool. Give each result set a stable identity so replacement of one analysis is not confused with aggregation of different scopes. The same tool and category can replace earlier results for a commit; multiple files with that identity in one Actions run are invalid configuration. Also investigate alerts that close and reappear without code changes. Different temporary paths and absent fingerprints can prevent linkage of the same issue across runs. Do not solve this by randomly changing ruleId or category each run. Normalize mapping to source and maintain consistent identity. Before concluding the backlog grew, distinguish new defects from duplication in how results are displayed and tracked.
3. Separate ingestion, display and completeness
Receiving a file does not mean displaying every finding. SARIF limits include rejection for excessive data and truncation of accepted sets. In the exercise, the original report contains 6,000 results and the view includes only 5,000. The difference of 1,000 needs reconciliation against triage policy, without assuming omitted findings are false positives. Retain the original and its candidate linkage; decide how to handle result volume and quality. If upload fails because URI schemes conflict with the source root, published evidence is missing rather than clean. Correct mapping and confirm processing. An absent annotation in the PR diff can also reflect location-display rules, so review must inspect the evidence set appropriate to the requirement.
4. Review the effective dependency tree
Updating a direct library can change several transitive dependencies. Review the lockfile and resolved tree, not just the changed manifest line. Confirm submitted data corresponds to the revision being compared. If submission takes longer than review, a race can leave snapshots missing. Coordinate operation order or use supported retries with a limit and completeness confirmation. A fixed delay does not establish submission completion. Also define which scopes policy covers: tools used only during build can influence the produced artifact. If configuration only fails runtime findings, success does not establish the development-scope policy. At handover, record versions, data origin and relevant exclusions so the next team knows what was actually analyzed.
5. Interpret failure and license controls
A required check only enforces the result produced by its configuration. With warn-only enabled, a vulnerability above the threshold can still produce success. Review action inputs before attributing the result to failed branch protection. Also keep vulnerability and license conditions separate. Under this lesson’s fictional policy, a license must be identified and approved. The action can report an unknown license without failing, but that does not satisfy this rule. Do not fill the gap by excluding the package from analysis. Route identification and decision to the appropriate owner. Account for version and platform differences: consulted configuration examples show different versions, and license capabilities on GitHub.com should not be assumed on GitHub Enterprise Server.
6. Treat secrets and exceptions as operational decisions
A secret removed from a file may remain valid at the service accepting it. Coordinate replacement or revocation, update consumers and investigate misuse in relevant logs. Avoid promising that closing any alert automatically revokes every external credential. Retain enough evidence to distinguish access recovery, code cleanup and administrative alert closure. Exceptions need a similar distinction: technical suppression is not authorization without an expiry. In the example, an exception ends in September but the filter remains in October. The new release requires reassessment of component, mitigation, owner and expiry. Do not extend a specific exception to every component with the same severity. The decision should let support understand accepted risk, boundaries and when reassessment is due.
7. Confirm coverage before interpreting dashboards
A healthy connector shows an integration works within its scope; it does not establish coverage of every candidate, language and analysis type. In the documented Defender for Cloud agentless preview, the default branch is an important boundary. Confirm support and configuration before using the result in a decision about another candidate. In Azure DevOps, enabling a feature also does not replace running the configured pipeline. With Advanced Security disabled, a task may not fail while results are unavailable and not retained. Define result-presence, date and revision checks. If one is missing, report the gap instead of filling the cell with zero vulnerabilities. An observed zero and an absence of observation support different decisions.
8. Apply a reproducible release review
Use the fictional records below as an exercise, not a real scanner report. Identify three gaps: a different revision, findings needing reconciliation and unidentified licensing. Write the needed action, owner and evidence that would close each one. The solution is not to conclude the candidate is vulnerable merely because data is missing; it is to recognize that acceptance conditions remain unproven. You can postpone the decision or obtain missing evidence within the available window. At RUN handover, provide links to full reports, artifact identity, configurations, limitations and current exceptions. The final summary should be short but traceable. Someone who did not follow the pipeline should be able to understand why the team approved the release or kept its decision pending.
{
"fictional": true,
"candidateCommit": "candidate-8",
"requirements": [
"candidate-specific analysis",
"all findings accounted for",
"identified approved license"
],
"codeScan": {
"commit": "candidate-7",
"completed": true
},
"sarif": {
"commit": "candidate-8",
"rawResults": 6000,
"includedResults": 5000
},
"dependency": {
"commit": "candidate-8",
"package": "fictional-funds-parser",
"license": "unknown",
"actionSucceeded": true
}
}A committee receives a green summary from another revision, a truncated view and an unknown license. The exercise requires identifying the concrete evidence missing before release acceptance.
Common pitfalls
Confusing upload with analysis; ignoring truncated results; using another revision’s evidence; extending exceptions through suppression; treating unknown licensing as approved.
Related topics: Artifact traceability and SBOM · Vulnerability and exception management · Credential-exposure response · Release governance and handover
A security decision connects candidate, coverage, findings and risk disposition. Tool success is useful only when its actual checks are understood.
Reference: SARIF support for code scanning · AZ-400 objectives 2026-07-27