DevSecOps English: Security Shift-Left and Threat Vocabulary

Introduction

DevSecOps integrates security practices into the entire software development lifecycle, rather than treating security as a gate at the end of the process. If your team is adopting DevSecOps practices, you will encounter a specific set of English terms in security reviews, pipeline discussions, and architecture conversations. Understanding this vocabulary helps you engage with security requirements, contribute to threat modelling sessions, and write clear security documentation.

Shift Left

The central concept of DevSecOps is shift left — moving security activities earlier in the development process, toward the left side of the software development timeline:

• “We shift security left by running SAST in CI” — catching vulnerabilities before code is deployed
• “Security is everyone’s responsibility, not just the security team’s” — a cultural statement of shift-left philosophy
• “We find issues in development, not in production” — the goal of shifting left
• security gate — a checkpoint in the pipeline that prevents progression if security checks fail; “we added a security gate that blocks merges if critical vulnerabilities are found”
• “Shift security left without creating friction” — the challenge of making security fast enough that developers adopt it

The phrase “shift left” comes from reading a development timeline from left (planning) to right (production). Security traditionally happens at the far right — after development. Shifting it left means doing it earlier, when fixes are cheaper and faster.

SAST, DAST, and SCA

Three types of automated security scanning are commonly discussed:

• SAST (Static Application Security Testing) — analyses source code for vulnerabilities without running the program; “we run SAST on every pull request using Semgrep”
• DAST (Dynamic Application Security Testing) — tests a running application by simulating attacks; “we run DAST against the staging environment before every release”
• SCA (Software Composition Analysis) — scans dependencies for known vulnerabilities; “SCA found that our logging library has a critical CVE — we need to update it”
• CVE (Common Vulnerabilities and Exposures) — a standardised identifier for a known vulnerability; “CVE-2021-44228 is the Log4Shell vulnerability”
• false positive — a vulnerability alert that is not actually exploitable in your context; “we triaged 30 SAST findings and 18 were false positives”

In code review discussions: “This SAST finding is a true positive — the SQL query is indeed vulnerable to injection. We need to use parameterised queries.”

Threat Modelling

Threat modelling is a structured process for identifying security risks in a design. The vocabulary:

• threat model — a document or diagram identifying assets, threats, and mitigations; “we conducted a threat model for the new API”
• STRIDE — a threat categorisation framework (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
• attack surface — the set of points where an attacker could try to enter or extract data; “adding a new public endpoint increases the attack surface”
• threat actor — a person or system that might attack you; “our primary threat actors are opportunistic attackers and disgruntled former employees”
• mitigate — reduce the risk of a threat; “we mitigate this threat with rate limiting and account lockout”
• residual risk — risk that remains after controls are applied; “the residual risk is accepted by the business owner”

Secrets and Supply Chain

Two rapidly evolving areas of DevSecOps vocabulary:

Secrets management:

• “We scan for hardcoded secrets” — checking that API keys, passwords, and tokens are not in the codebase
• secrets sprawl — secrets being stored in many insecure places; “we have secrets sprawl — credentials are in CI environment variables, Slack, and local .env files”
• “We rotate secrets on a schedule” — periodically replace credentials to limit exposure

Supply chain security:

• SBOM (Software Bill of Materials) — a list of all components in your software; “we generate an SBOM for every release to support compliance requirements”
• dependency confusion attack — a supply chain attack where a malicious public package with the same name as an internal package is installed instead; “we use scoped package names to mitigate dependency confusion”
• “We pin dependency versions” — using exact version numbers to avoid unexpected updates

Key Vocabulary

Term	Definition
shift left	Moving security activities earlier in the development process
SAST	Static Application Security Testing — scanning source code for vulnerabilities
DAST	Dynamic Application Security Testing — attacking a running application
SCA	Software Composition Analysis — scanning dependencies for known vulnerabilities
CVE	A standardised identifier for a publicly known vulnerability
threat model	A structured analysis of potential attacks on a system
attack surface	All the points where an attacker could enter or extract data
mitigate	Reduce the likelihood or impact of a security threat
SBOM	Software Bill of Materials — an inventory of all software components
secrets sprawl	Credentials stored in many insecure, unmanaged locations

Practice Tips

1. Run a SAST tool on your codebase and triage the findings in English. For each finding, write a short note: “This is a true positive — the input is user-controlled and must be sanitised. Mitigation: use a parameterised query.” or “This is a false positive — the data comes from an internal system and is not user-controlled.”

2. Practise explaining “shift left” to a developer who is resistant to security tasks. The key argument: “Finding a vulnerability in a pull request takes 10 minutes to fix. Finding it in production after a breach takes months and costs the company’s reputation.”

3. Learn the difference between SAST and DAST. This is a common interview question for DevSecOps roles. “SAST analyses code without running it — it’s like proofreading. DAST tests a running application — it’s like penetration testing in an automated way.”

4. Use “mitigate” precisely. In security, mitigate means reduce the risk, not eliminate it. “We mitigate the risk of credential theft by rotating secrets quarterly” is correct. Avoiding the word “prevent” when the risk still exists shows precision.

Conclusion

DevSecOps vocabulary — shift left, SAST, DAST, SCA, threat model, attack surface, SBOM — describes a security philosophy that treats security as an integrated engineering concern rather than a final checkpoint. Understanding and using these terms helps you participate in security reviews, contribute to threat modelling sessions, and advocate for security practices in your team. As organisations face increasing regulatory and customer pressure around security, this vocabulary will only become more central to engineering discussions.