Book 21 · A book in progress

Security Is an Engineering Job

From experienced developer to application and product security in the age of AI.

Learn to investigate a failure, repair its cause and verify the result. These essays connect security reasoning to the software you already know how to build, with worked examples and practice.

Fourteen essays available. New chapters will extend the path into application security, secure delivery and AI systems.

Start reading

  1. Which security job uses what you already know?

    Choose the responsibility that builds on your engineering experience, and identify the evidence you still need.

  2. A security requirement must survive a hostile input

    Turn a document-export feature into testable rules for identity, permission and changes over time.

  3. Draw the boundary before choosing the control

    For each decision, name the facts it reads and who can write them, then judge whether proposed controls sit at those crossings.

  4. A valid user can still read the wrong invoice

    Reproduce cross-tenant access in a Spring Boot lab, repair the lookup, and follow the same check into the export worker and download.

  5. A signed token answers only the question you validate

    Reject a valid token intended for another API, then examine purpose, account recovery and the limits of local verification.

  6. The browser brings authority to the request

    Trace a forged form and an injected script through one browser session, and repair each at its actual boundary.

  7. Input becomes dangerous when it changes the grammar

    Trace a title into a SQL predicate, repair its binding, and distinguish injection prevention from tenant authorization.

  8. A fetch endpoint borrows the server’s network access

    Trace an approved URL through a forbidden redirect, then design the destination policy for a second approved origin and prove the forbidden one stays unreachable.

  9. A file becomes a program in the component that opens it

    Trace stored XML into a parser’s file and network access, repair the interpretation boundary, then review a release whose new consumers you must assess yourself.

  10. Two valid requests can violate one business rule

    Control a credit race, distinguish duplicate from partial effects, and choose tests for a second caller.

  11. Review the security property, including in generated code

    Trace each path that can return protected data, challenge a generated release with your own tests, and defend what the evidence permits you to approve.

  12. A useful detector has known misses

    Build a tested SQL detection rule, execute the vulnerable wrapper it misses, then maintain the rule against a module written after it.

  13. An SBOM records what a particular build contains

    Compare a Maven dependency BOM with two finished images, find the separately copied component, then decide which inventory records actually describe a selected release.

  14. The highest severity is not automatically the first fix

    Use dated threat data and deployment evidence to defend remediation, investigation and deferral, then decide again when the evidence moves.

  15. The build system is a production credential

    Trace a fork’s change into the job that holds the release token, split the workflow so it never can, then verify as the consumer what a signed release proves and what it does not.

  16. A workload carries only the authority its task needs

    Replace a shared, never-expiring key with a job identity, a trust policy and a short session, then write the role for a job that deletes things and defend every claim in it.

Learn by making a decision

The opening essays use a document-export service to connect roles, requirements and security evidence. Read in order, attempt the exercise, then compare your reasoning with the review notes where provided.

Begin with essay 1 →