English for Security Champion Programs

Security champion programs embed security expertise directly inside development teams, bridging the gap between dedicated security professionals and the engineers writing code every day. If you work in or alongside one of these programs, you need specific English vocabulary to discuss threats, review code, triage vulnerabilities, and promote a security-first culture without sounding alarmist or vague. This guide gives you the language to do exactly that.

Key Vocabulary

Security champion — a developer within a product team who takes on responsibility for raising security awareness and facilitating security practices within that team. “Our security champion coordinates with the AppSec team and runs monthly secure coding workshops for the squad.”

Threat modeling — a structured process for identifying, quantifying, and addressing security threats to a system. “Before we finalise the architecture, let’s run a threat modeling session to identify the main attack vectors.”

Attack surface — the sum of all potential entry points where an attacker could attempt to gain access to a system. “By removing the public-facing admin endpoint, we significantly reduced the attack surface.”

Vulnerability triage — the process of assessing and prioritising security vulnerabilities based on their severity and exploitability. “After the scanner run, we have 47 findings. Triage shows three are critical, the rest are medium or low.”

Secure code review — a manual or automated review of source code with the goal of identifying security vulnerabilities. “The security champion conducted a secure code review of the authentication module before it was merged.”

DAST / SAST — Dynamic Application Security Testing (run against a live application) and Static Application Security Testing (run against source code). “Our CI pipeline includes SAST at build time, and DAST runs against the staging environment nightly.”

Security debt — accumulated security issues that have been deferred and not yet remediated. “We’ve built up significant security debt in the legacy payment service — we need to schedule a remediation sprint.”

Shift left — the practice of moving security activities earlier in the development lifecycle, rather than addressing them at the end. “Shifting left means our developers catch vulnerabilities during code review, not after deployment.”

Common Phrases for Threat Modeling Sessions

Use these in workshops or architecture reviews.

• “What are the trust boundaries in this design — where does data cross from a trusted to an untrusted zone?”
• “Who are the likely threat actors, and what are their capabilities and motivations?”
• “Using the STRIDE model: where in this flow could an attacker spoof a user identity?”
• “What would the blast radius be if this service were compromised?”
• “Let’s walk through the data flow and flag any points where sensitive data is persisted or logged unintentionally.”

Secure Code Review Language

• “I noticed the user input here is concatenated directly into the SQL query — this is a potential injection point.”
• “There’s no output encoding on this field, which could expose us to a reflected XSS vulnerability.”
• “Secrets should not be hardcoded — this API key needs to move to the secrets manager.”
• “The error message reveals internal stack trace details. We should return a generic error to the client.”
• “This endpoint lacks rate limiting, which could make it a target for credential stuffing.”

Vulnerability Triage Phrases

• “This is a CVSS 9.1 critical — it’s remotely exploitable without authentication. It needs an emergency patch.”
• “This medium-severity finding is in a component with no external exposure, so the exploitability is low. We’ll schedule it for next sprint.”
• “We’re marking this as a false positive — the finding relates to a library function we don’t actually call.”
• “We’ve accepted the risk on this low-severity issue pending a compensating control.”

Professional Tips

1. Lead with risk, not rules. Instead of “this violates policy,” say “this creates a risk of account takeover that could affect 50,000 users.”
2. Avoid blame in code reviews. Use passive constructions: “a potential injection point exists here” rather than “you wrote an injection vulnerability.”
3. Use severity consistently. Define what critical, high, medium, and low mean in your context, and stick to those definitions.
4. Celebrate fixes, not just findings. Security culture improves when teams are recognised for fixing issues, not only blamed for introducing them.

Practice Exercise

1. A developer pushes code that concatenates user input into a SQL query. Write a code review comment (3-4 sentences) that is factual, non-blaming, and explains the risk.
2. Your team has 20 open vulnerabilities. Write 4-5 sentences describing how you would triage them and explain your prioritisation logic to the engineering manager.
3. You are asked to explain “shift left” to a product manager who has no security background. Write a 3-sentence plain-language explanation.