DevSecOps interview questions usually test much more than basic security terminology. Interviewers generally want to know whether you can integrate security into the development and CI/CD lifecycle without slowing delivery unnecessarily.
DevSecOps brings security into the same workflow used by development and operations teams. Modern guidance emphasizes continuous security validation, threat modeling, secure pipelines, automated scanning, secrets management, and secure infrastructure.
1. What is DevSecOps?
DevSecOps is an approach where security is integrated into the DevOps lifecycle from development through deployment and operations rather than being treated as a final security check before production.
The basic idea is:
Plan → Code → Build → Test → Secure → Deploy → Monitor
The goal is to identify security problems as early as possible, when they are generally easier and cheaper to fix.
2. What is Shift-Left Security?
Shift-left security means moving security activities earlier in the software development lifecycle.
Instead of discovering a vulnerability after the application reaches production, security checks can be performed during:
- Design
- Coding
- Pull requests
- Build
- Testing
- Deployment
For example, a CI pipeline can automatically scan source code and dependencies before allowing a release to continue. Microsoft describes DevSecOps as embedding security throughout development and operations rather than applying security only at the end.
3. What is SAST?
SAST stands for Static Application Security Testing.
It analyzes source code, bytecode, or application code without executing the application.
It can identify problems such as:
- SQL injection risks
- Insecure coding patterns
- Hard-coded credentials
- Unsafe functions
- Potential security weaknesses
A SAST tool can be integrated into a CI pipeline so developers receive feedback before code reaches production.
4. What is DAST?
DAST stands for Dynamic Application Security Testing.
Unlike SAST, DAST tests a running application from the outside.
For example:
Application deployed in test environment → DAST scanner → Security findings
DAST can identify vulnerabilities that may only become visible when the application is running.
OWASP identifies SAST, DAST, IAST, SCA, infrastructure scanning, and container scanning as common components of a DevSecOps pipeline.
5. What is SCA?
Software Composition Analysis (SCA) examines third-party and open-source dependencies used by an application.
For example, an application might depend on:
- npm packages
- Python packages
- Java libraries
- Container packages
If one of those dependencies contains a known vulnerability, SCA can identify it.
This is important because modern applications frequently depend on large numbers of third-party components, making software supply-chain security an important DevSecOps concern.
6. How Would You Secure a CI/CD Pipeline?
A strong interview answer should cover multiple layers.
I would consider:
- Strong authentication and MFA
- Least-privilege permissions
- Secure service identities
- Protected branches
- Code review
- Secret management
- SAST
- SCA
- DAST
- IaC scanning
- Container image scanning
- Artifact integrity
- Audit logging
- Manual approval for sensitive production deployments
- Pipeline isolation
The pipeline itself is part of the attack surface. An attacker who compromises a CI/CD system may potentially gain access to source code, credentials, artifacts, or production environments. OWASP recommends securing automation servers, restricting access, enabling logging, incorporating security scanning, and protecting production deployment processes.
7. How Do You Manage Secrets in DevSecOps?
Secrets should never be stored directly in source code or committed to Git repositories.
Examples of secrets include:
- Passwords
- API keys
- Access tokens
- Database credentials
- Certificates
- Cloud credentials
Instead, use a dedicated secrets-management solution such as a cloud key vault or another approved secret manager.
The application or pipeline should retrieve secrets securely when they are needed.
Microsoft specifically recommends storing secrets in protected vaults rather than in code or team environments.
8. What Is Threat Modeling?
Threat modeling is a structured process for identifying potential threats and security risks before or during application development.
A team might ask:
- What assets are we protecting?
- Who could attack the system?
- What entry points exist?
- What could go wrong?
- What controls can reduce the risk?
For example, for an e-commerce application, threat modeling might identify risks around authentication, payment processing, APIs, databases, and administrative interfaces.
Threat modeling is an important DevSecOps practice because it addresses security at the design stage rather than waiting for a vulnerability to appear during production.
9. How Would You Secure Docker Containers?
A good answer should include:
- Use trusted base images
- Keep images updated
- Scan images for vulnerabilities
- Avoid unnecessary packages
- Run containers as non-root where possible
- Do not embed secrets in images
- Use minimal images
- Sign and verify images where appropriate
- Restrict container privileges
- Monitor running containers
Container security should cover both the image-building stage and runtime environment.
10. How Do You Secure Kubernetes?
Important areas include:
- RBAC
- Network policies
- Pod security controls
- Image scanning
- Secrets management
- Admission controls
- Namespace isolation
- API-server security
- Audit logging
- Resource limits
- Regular patching
For example, giving every application administrator-level Kubernetes permissions would violate least-privilege principles.
11. How Do You Secure Infrastructure as Code?
Infrastructure as Code should be treated like application code.
For Terraform, Bicep, CloudFormation, or similar technologies, you can introduce:
Code → Pull Request → IaC Security Scan → Review → Build → Approval → Deployment
IaC scanning can identify issues such as:
- Publicly exposed storage
- Overly permissive firewall rules
- Weak IAM permissions
- Unencrypted resources
- Insecure network configurations
Modern DevSecOps guidance explicitly includes infrastructure configuration and IaC scanning as part of the security lifecycle.
12. What Is Software Supply Chain Security?
Software supply-chain security protects the components and processes used to build and deliver software.
This includes:
- Source repositories
- Third-party dependencies
- Build systems
- CI/CD pipelines
- Container images
- Package repositories
- Build artifacts
- Deployment systems
An attacker doesn't necessarily need to compromise the application directly. Compromising a dependency, build process, package, or CI/CD integration can provide another route into the software supply chain.
Therefore, dependency scanning, trusted sources, artifact integrity, access control, and pipeline security are important parts of DevSecOps.
13. What Would You Do If a Security Scan Fails the Pipeline?
I wouldn't automatically ignore the failure just to complete the deployment.
First, I would determine:
- What vulnerability was detected?
- What severity does it have?
- Is it actually exploitable?
- Which component is affected?
- Is a patched version available?
- Does the issue require immediate remediation?
- Can the deployment safely continue under an approved exception?
For critical vulnerabilities, the pipeline may need to block deployment.
For lower-risk findings, an organization may use a defined risk-acceptance or remediation process.
The important point is that DevSecOps should combine automation with risk-based decision-making, rather than blindly blocking every finding.
14. How Do You Avoid Too Many False Positives?
Security tools can generate findings that are technically suspicious but not practically exploitable.
A good process is:
Scan → Prioritize → Validate → Remediate → Suppress/Accept with justification when appropriate
Security teams should prioritize issues based on factors such as severity, exploitability, asset importance, and production exposure.
This helps developers focus on the vulnerabilities that actually represent meaningful risk.
15. How Would You Integrate Security into a CI/CD Pipeline?
A practical pipeline could look like:
Developer Commit
↓
Secret Detection
↓
SAST
↓
SCA / Dependency Scan
↓
Build
↓
Container Image Scan
↓
IaC Scan
↓
Deploy to Test
↓
DAST
↓
Security & Quality Gates
↓
Approval
↓
Production Deployment
↓
Runtime Monitoring
OWASP recommends integrating security testing such as SAST, DAST, SCA, IaC scanning, and infrastructure/container scanning into DevSecOps workflows.
16. What Is the Difference Between DevOps and DevSecOps?
The simplest distinction is:
DevOps:
Development + Operations + Automation
DevSecOps:
Development + Security + Operations + Automation
DevSecOps doesn't mean creating a completely separate security process. The objective is to make security part of the existing development and operations workflow.
17. How Do You Secure the CI/CD Pipeline Itself?
This is a particularly good interview question because candidates often focus only on application security.
I would protect the pipeline through:
- MFA
- Least privilege
- Short-lived credentials where possible
- Secure service identities
- Protected branches
- Restricted pipeline permissions
- Isolated build agents
- Audit logging
- Approved integrations
- Secure artifact repositories
- Secret scanning
- Pipeline configuration reviews
The CI/CD system itself can become a high-value target because it may have permissions to deploy directly into production. Microsoft specifically highlights pipeline credentials, integrations, runtime variables, and excessive permissions as potential attack surfaces.
18. What DevSecOps Tools Should You Know?
The exact tools vary by organization, so it is better to understand security categories rather than memorize product names.
OWASP's DevSecOps guidance covers many of these categories and emphasizes integrating security checks into the development pipeline.
19. Scenario-Based Question: A Developer Accidentally Commits an API Key. What Do You Do?
A strong answer would be:
First, revoke or rotate the exposed credential.
Then:
- Determine where the credential was exposed.
- Check whether it was accessed or misused.
- Remove it from the repository and relevant artifacts.
- Replace it with a managed secret.
- Scan repository history if necessary.
- Review permissions associated with the credential.
- Add secret scanning to prevent recurrence.
- Document the incident and improve the process.
Simply deleting the key from the latest commit is not always sufficient because credentials can remain in repository history.
20. Scenario-Based Question: A Critical Vulnerability Is Found Before Production
I would first assess the vulnerability's severity, exploitability, affected component, and production exposure.
If it represents an unacceptable risk, I would stop or hold the deployment, identify a patched version or mitigation, retest the application, and then continue through the release process.
If business circumstances require accepting the risk temporarily, that should happen through an explicit, documented risk-acceptance process rather than silently bypassing the security control.
Final Thoughts
For a DevSecOps interview, don't focus only on memorizing definitions such as SAST, DAST, SCA, and Shift Left. Interviewers are often more interested in whether you can explain how security fits into a real software delivery pipeline.
A strong candidate should be able to explain:
Secure Code → Secure Dependencies → Secure Build → Secure Infrastructure → Secure Deployment → Secure Runtime
The most important areas to prepare are CI/CD security, SAST, DAST, SCA, secrets management, threat modeling, container security, Kubernetes security, IaC scanning, vulnerability management, supply-chain security, IAM, and incident response.
Most importantly, be prepared with real examples. Instead of saying “I know SAST,” explain where you would put it in a pipeline, what happens when it finds a critical vulnerability, who reviews the result, and how the issue is remediated. That kind of practical explanation usually demonstrates much stronger DevSecOps understanding.