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.

Navigating the Security Landscape – A Practical Approach

DevSecOps isn’t just about tools; it’s fundamentally a shift in mindset – one that prioritizes integrating security throughout the entire software development lifecycle. Understanding the specific English vocabulary associated with this approach is critical, especially for developers coming from different backgrounds or those working internationally. Let’s break down some key terms and how they are typically used in professional discussions, focusing on clarity and precision rather than just literal translations. A core concept here is shift-left, meaning addressing security concerns early – during design and development – instead of waiting until the end. This proactive approach significantly reduces risks and costs associated with remediation later. Furthermore, understanding threat modelling – systematically identifying potential threats to a system – is crucial for informed decision making.

One common challenge is translating concepts accurately between languages. For example, simply saying “security early” doesn’t convey the nuanced meaning of “shift-left.” It’s about embedding security practices into every stage, from initial requirements gathering through testing and deployment. Another key area is SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing). While ‘static’ might seem purely mathematical, in this context it refers to analyzing the source code without running the application, while ‘dynamic’ involves actively testing the running application – a critical distinction. Similarly, when discussing secrets management, we aren’t just talking about keeping passwords safe; it’s about controlling access to sensitive information like API keys and database credentials throughout their entire lifecycle, implementing robust controls and auditing mechanisms. Finally, with increasing emphasis on supply chain security, developers need to understand the risks associated with third-party components and how to verify their integrity – a complex area requiring careful due diligence.

The goal isn’t simply to use buzzwords; it’s about communicating effectively and collaboratively within a DevSecOps team. Phrases like “Let’s incorporate security requirements into the initial design phase” or “We need to perform a threat model before proceeding with development” are much clearer than vague statements. Remember, clear communication is paramount when identifying vulnerabilities early on and fostering a culture of shared responsibility for security. It’s about building a common understanding that security isn’t an afterthought; it’s woven into the fabric of every decision we make.

# Example: Using `npm audit` to identify vulnerabilities in Node.js dependencies
npm audit --production

This command, using npm, is a simple example of how developers actively use tools to shift-left – identifying security issues within project dependencies before deployment. The output provides details about potential vulnerabilities and suggests remediation steps, demonstrating the practical application of securing software early in its lifecycle. The key takeaway here is that vocabulary translates directly into actionable processes and practices.