Shipping Without Saying No: The First 180 Days in AppSec and AI Security

Name: PlayCISO
Price: 5.00 USD

How to make software and AI features safer while the people who build them keep shipping.

You were hired to make software safer. The people who write that software were hired to ship it. This book is about doing your job without becoming the reason theirs got harder.

It runs in time order, from your first day to about six months in. Each chapter starts with the questions people tend to ask quietly, then gives plain answers and ends with one thing to practise on PlayCISO.

Read it straight through once, then come back to the chapter that matches your week. Nothing here needs a budget. Most of it needs conversations.

Start reading Read it on one page

Day 1: listen before you scan

Before any tool runs, learn who builds what, how code reaches production and what is already live.

Meet the engineers before the scannersDay 1
Find the pipelineDays 1–5
What is already shippingWeek 1

The first 30 days

The working habits that make AppSec useful: quick threat models, calm triage, the supply chain and AI features.

Threat modelling a feature in an hourWeeks 2–4
Triaging scanner output without drowning devsWeeks 2–4
Secrets, dependencies and the supply chainWeeks 2–4
AI features: prompt injection and what the model can doWeeks 3–4
Model files, MCP servers and an AI bill of materialsWeeks 3–4

What if I screw up?

Something will ship that should not have. How you respond matters more than the fact that it happened.

A vulnerability shippedAny time
An AI feature leaked dataAny time
Running a blameless reviewAfter any incident

How am I doing?

Measure what changes risk and what developers feel, not how many findings a tool produced.

Measure time to fix, not findings countMonths 2–3

Choose your own adventure: 180 days

By month six you know the place. Pick one deeper programme that fits what you have learned.

Four paths for months 4 to 6Months 4–6

Epilogue

What AppSec as a field is not good at, so you can avoid repeating it.

What AppSec is not good atMonth 6 and after

Glossary

AI bill of materials (AIBOM): A list of the models, datasets and AI components a system uses, with versions and sources.
API: Application programming interface: a way for programs to talk to each other.
AppSec: Application security: making the software an organisation builds or buys safer.
Artefact: A file produced by a build, such as a container image or package, that gets deployed.
Attack surface: Every place an attacker could try to interact with a system.
Blameless review: An incident review that looks for system causes rather than a person to blame.
BOLA: Broken Object Level Authorization: one user reaching another user’s data by changing an identifier.
Branch protection: Rules that stop changes reaching a main branch without review or checks.
CI/CD: Continuous integration and delivery: the automated pipeline that builds, tests and deploys code.
Container image: A packaged application with everything it needs to run.
CVE: Common Vulnerabilities and Exposures: a public identifier for a known vulnerability.
DAST: Dynamic application security testing: testing a running application from the outside.
Dependency: Third-party code your software relies on, such as an open source package.
Excessive agency: An AI feature able to take more actions, or broader ones, than it needs.
False positive: A finding that a tool reports but that is not a real problem.
Feature flag: A switch that turns a feature on or off without a new deploy.
Git history: The full record of past changes in a repository, including deleted content.
Guardrail: A check or limit around an AI model that catches or blocks unwanted behaviour.
IAST: Interactive application security testing: watching the application from inside while it runs.
Indirect prompt injection: Instructions hidden in content an AI model reads, written by someone other than the user.
Injection: Untrusted input treated as code or commands, such as SQL injection.
Inventory: A list of what an organisation runs, with owners and exposure.
Least privilege: Giving a person, service or tool only the access it needs, and no more.
LLM: Large language model: an AI model that reads and writes text.
Lock file: A file that records the exact versions of every dependency a project uses.
MCP: Model Context Protocol: a standard way for AI assistants to connect to tools and data.
MCP server: A program that exposes tools or data to an AI assistant over MCP.
ML-BOM: Machine learning bill of materials: the CycloneDX format for listing models and datasets.
Model card: A short document describing a model, how it was trained and its limits.
OWASP: Open Worldwide Application Security Project: a non-profit that publishes free security guidance.
Pickle: A Python file format that can run code when loaded; risky for untrusted model files.
Pinning: Fixing a dependency or plugin to an exact version so it cannot change silently.
Pipeline: The automated steps that take code from a commit to production.
Prompt injection: Text that makes an AI model follow an attacker’s instructions instead of the intended ones.
Pull request: A proposed code change that others review before it is merged.
Red team: People who test a system by acting as an attacker, with permission.
Rotation: Replacing a secret with a new one and retiring the old one.
Safetensors: A model file format that stores weights only, without code that runs on load.
SAST: Static application security testing: scanning source code without running it.
SBOM: Software bill of materials: a list of the components inside a piece of software.
SCA: Software composition analysis: tools that find known problems in dependencies.
Scope: The set of permissions a token or credential grants.
Secret: A password, key or token that grants access and must be kept private.
Security champion: A developer with an interest in security who acts as a link between a team and AppSec.
Severity: How bad a flaw would be if exploited, often combined with exposure to set priority.
Supply chain: Everything outside your own code that goes into what you ship, including your build tools.
System prompt: Hidden instructions given to an AI model by the application, not the user.
Threat model: A structured look at what could go wrong with a system and what to do about it.
Time to fix: How long a confirmed flaw stays open, from discovery to a fix in production.
Token passthrough: An MCP server forwarding a token it did not check was issued to it; the MCP spec forbids it.
Trust boundary: A point where data or control passes between parts with different levels of trust.
Typosquatting: Publishing a malicious package with a name close to a popular one.

Frequently asked questions

What should a new AppSec engineer do in the first 30 days?

Meet engineers, map the build pipeline and list what is already running in production. Then run one short threat model, start triaging scanner output and get secret detection in place.

Is the OWASP Top 10 still relevant in 2026?

Yes. The current edition is the OWASP Top 10:2025, which lists Broken Access Control first and adds Software Supply Chain Failures. For AI and APIs, use the OWASP LLM Top 10 2025 and the API Security Top 10 2023.

How do I stop developers ignoring security findings?

Send fewer, better findings. Group duplicates, drop noise, confirm the top items by hand and explain each fix in the team’s own terms.

What is the biggest security risk in AI features?

Prompt injection is first on the OWASP LLM Top 10 2025. The practical defence is to limit what the AI feature can read and do, so a manipulated model causes little harm.

What metrics should AppSec report?

Time to fix by severity, open serious findings on internet-facing services and pipeline coverage of critical services. Raw findings count mostly measures how noisy your tools are.

Other handbooks

Updated 2026-11-14. General guidance, not legal advice. Where a chapter states a law or standard, its sources are listed at the end of that chapter.