SECNET / FIELD GUIDE · Engineering

Application security: build a repeatable assurance loop

AppSec is a product lifecycle, not a release-day scanner. Tie each control to a threat, an owner and evidence. Use ASVS 5.0.0 as a versioned requirements reference and WSTG 4.2 for relevant web test procedures; a Top 10 checklist alone is not a complete verification program.

SecNet learning series · 1.0 · Source check: 2026-10-11

Original SecNet educational content. Examples are fictional; this is not a publication or endorsement by the referenced organizations.

Code modules pass testing, dependency inspection and release gates on a delivery conveyor.
Original AI-assisted educational illustration; not an incident photograph or technical architecture.
SECNET / VISUAL LAB · WEB / APPSEC

Web security · a request under inspection

Follow a request through distinct control points. Select a case to see where it stops.

INTERACTIVE
BrowserTLS / edge filterSessionObject permissionInput validationData operation
01 / 06 · Browser

The illustrated request passes each check. An edge filter does not replace application authorization.

Show process diagram
Inventory → Design → Build → Verify → Observe
A summary of the workflow; detailed steps follow below.

How to plan and execute

  1. Inventory applications, APIs, data classes and business-critical operations. Agree assurance depth by impact, including service identities and administrative paths.
  2. Draw data flows and trust boundaries with product and engineering teams. Turn misuse cases into explicit requirements: who may read, change, export or delete each object?
  3. Place lightweight code, dependency and secret checks in pull requests. Assign alert ownership and expiry for justified exceptions; avoid blocking releases on untriaged duplicates.
  4. Exercise authenticated roles and API contracts in staging. Test object authorization, logout/revocation, file handling and sensitive business transitions beyond crawler coverage.
  5. Set a release decision with confirmed impact, residual risk, accountable acceptance and rollback readiness. Link the assessment to an immutable source/build identity.
  6. Monitor abuse signals and dependency changes after release. Feed incidents and escaped defects back into requirements and regression tests rather than repeating a one-off scan.

Tools & work records

  • Semgrep — code analysis selected for the project’s languages; tune rules with confirmed examples and document suppressions.
  • Trivy — dependency/container/configuration assessment; record the scanned artifact digest and advisory database date.
  • ZAP — targeted staging web checks with authenticated test accounts; authorization still needs explicit negative tests.

What reports are produced?

  • Threat model and versioned requirements-to-evidence matrix.
  • Confirmed defect backlog with code owner, affected build and regression test.
  • Release assurance note with residual risks, exceptions and post-release signals.
FICTIONAL WORKED EXAMPLE

Connect the decision to evidence

Fictional feature: a document export endpoint is protected by a hidden UI button but lacks object authorization. The AppSec loop adds an ownership rule to the design, validates it at the service boundary, and tests two roles with synthetic documents. The release record links the fixed source SHA and the negative test; the team monitors denied export attempts without logging document contents.

Closure check

  • Controls connected to an actual threat and owner?
  • Authenticated and negative tests included?
  • Exceptions have a review date and accountable acceptance?
Download report workpaper (.md) ↓

Official sources

Use these sources for criteria, tools and regulations; verify applicability and version for the actual assessment.