DevSecOps and Secure SDLC Questions

Covers integrating security into the software development lifecycle and operational pipelines. Topics include securing continuous integration and continuous delivery pipelines, automated security testing such as static application security testing, dynamic application security testing, and software composition analysis, dependency and container image scanning, secrets management in pipelines, vulnerability management, security gates and shift left security practices. Also includes infrastructure as code security, runtime and deployment security, compliance automation, interpreting and tuning security tool output to reduce false positives, and designing secure development architecture that enables rapid delivery while maintaining required security controls.

EasyTechnical

46 practiced

Explain the concept of 'shift-left' in the software development lifecycle. Give at least three concrete examples of shift-left practices (tooling/process) in a CI/CD pipeline, explain where they run (local, PR, CI, pre-commit), and describe the trade-offs between early feedback and developer productivity.

HardTechnical

49 practiced

Create a migration plan to bring 200 legacy applications (mostly monolithic, many on-prem) into a modern DevSecOps model over 12 months. Prioritize groups, define milestones, infrastructure changes required (CI, artifact repos, containerization), automation targets, risk mitigations, and how to measure progress. Include quick wins and pilot strategy.

Sample Answer

**Overview & objective** Migrate 200 legacy monoliths into a DevSecOps model in 12 months, delivering secure, automated CI/CD, containerized deployments, and measurable risk reduction while minimizing business disruption.

**Prioritization (groups)** - Tier 1 (Q1): Business-critical, internet-facing, high-risk (30 apps) - Tier 2 (Q2): High-change/active dev (70 apps) - Tier 3 (Q3): Low-change, stable (100 apps) Prioritize by risk score (business impact × exposure × technical debt) and compliance needs.

**12‑month milestones (quarterly)** - Month 0–2: Governance, standards, pilot selection (5 apps), toolchain procurement. - M3–M5: Pilot execution, CI templates, artifact repo, secrets vault, SAST/SCA integration. - M6–M8: Scale pipelines, containerize Tier 1, deploy orchestrator clusters, IaC for infra. - M9–M11: Migrate Tier 2, enable DAST and runtime protections (WAF, EDR, RBAC). - M12: Migrate Tier 3, finalize metrics, handoff and continuous improvement.

**Pilot strategy & quick wins** - Select 5 representative apps (one critical, one web, one batch, one DB-heavy, one internal). - Deliver end-to-end pipeline in 6–8 weeks: Git → CI (e.g., GitLab/Concourse) → artifact repo (Nexus/Artifactory) → container images → staging deploy. - Quick wins: central artifact repo, secrets manager (HashiCorp Vault), baseline pipeline templates, automated SAST/SCA, policy-as-code.

**Infrastructure & tooling changes** - Source control standardization (branching + signed commits). - CI system with pipeline-as-code. - Artifact repository for binaries and container registry. - Containerization (Docker) and orchestration (Kubernetes) with namespace RBAC. - IaC (Terraform) and config management. - Security tooling: SAST, SCA, DAST, IaC scanning, image scanning, runtime EDR, WAF. - Secrets management, key rotation, centralized logging, and monitoring (Prometheus/ELK).

**Automation targets** - 100% code scanned on commit (SAST/SCA) - 90% automated build → test → deploy for Tier 1 by M8 - Automated image scanning and policy gate for production

**Risk mitigations** - Use strangler pattern for large monoliths (incremental extraction) - Canary and blue/green deployments, automated rollback on failure - Maintain backups and DB migration rollback plans - Security gating: deny-by-default pipeline policies, exceptions only via approved risk register - Staged rollouts with business owners and disaster recovery playbooks

**Measures of progress & KPIs** - % apps on CI/CD pipelines - % containerized apps by tier - Mean time to deploy (MTTD/MTTR) and lead time for changes - Number of critical/high vulnerabilities over time - % of releases with automated security checks passed - Incidents attributable to deployment changes

**Governance & training** - Define DevSecOps standard, pipeline security baselines, and approval flows. - Developer training, runbooks, and security champions program.

This plan focuses on fast pilots, measurable automation, secure defaults, and incremental migration patterns to reduce risk while delivering DevSecOps capabilities in 12 months.

HardSystem Design

50 practiced

Architect an RBAC and tenant isolation model for a shared CI/CD platform serving thousands of developers and hundreds of teams. Address secrets isolation, artifact repository separation, quota enforcement, identity integration (SSO/IdP), and an onboarding workflow that grants least privilege. Explain how to handle cross-tenant shared libraries and operator privileges.

Sample Answer

**Clarify goals & constraints**- Shared CI/CD for 100s teams, thousands devs; strong tenant isolation, least privilege, SSO integration, secrets/artifact separation, quota enforcement, safe shared libs, limited operator power.

**High-level model**- Logical tenants mapped to Org/Team namespaces; resources namespaced at platform layer (pipelines, runners, artifact repos, secrets). Central control plane enforces policies; data plane hosts tenant workloads isolated by cgroups/K8s namespaces and network policies.

**Identity & RBAC**- Integrate with IdP (SAML/OIDC) + SCIM for groups. Map IdP groups → platform roles (Owner, Maintainer, Developer, ReadOnly) scoped per-tenant. Use attribute-based access control (ABAC) for dynamic policies (e.g., project=payments AND env=prod).

**Secrets isolation**- Per-tenant secret stores (vault namespaces). Path ACLs tied to tenant roles; short-lived dynamic credentials (database/registry) issued via Vault leases. No secret material in pipeline logs; inject at runtime with ephemeral tokens.

**Artifact repositories**- Per-tenant repositories (scoped repos in Nexus/Artifactory) with repo-level ACLs and immutable tags for prod. Cross-tenant sharing only via signed SBOM/artifact promotion to a shared curated repo.

**Quota & enforcement**- Central quota service enforces compute, storage, API rate limits by tenant. Admission controller rejects builds exceeding limits; throttling + billing/alerting on usage.

**Onboarding & least privilege**- Automated onboarding workflow: provision tenant namespace, create default roles with least privilege, require approval for elevated roles. Use ephemeral admin invites, 2-step approval for owner role, and policy-as-code templates (OPA/Gatekeeper) to validate defaults.

**Cross-tenant shared libraries**- Host shared libs in a curated central repo. Consumption via signed, versioned artifacts; consumers must pull from central read-only repo or promote vetted snapshots into tenant repo. CI pipeline policy checks signatures and SBOMs.

**Operator privileges**- Operators have split-plane admin: read-only visibility across tenants for monitoring; write/admin only on control plane resources (infra, platform configs) but not tenants’ secrets/artifacts. All operator actions logged, require Just-In-Time access via bastion + approval workflow, and audited with immutable logs.

**Trade-offs & compliance**- Namespace isolation + per-tenant services increases overhead but minimizes blast radius. ABAC + OPA gives flexibility but needs policy governance. Implement SSO/SCIM for lifecycle sync to reduce orphan accounts; enforce SOC/PCI controls where applicable.

**Metrics & validation**- KPIs: time-to-onboard, number of cross-tenant access incidents, secret lease expirations, quota violations. Regular pentests and policy reviews.

MediumSystem Design

54 practiced

Design an approach to run security tests on pull requests that balances fast developer feedback with thoroughness. Which checks should run synchronously on PRs vs asynchronously post-merge? How would you present results to developers to maximize actionability and minimize noise?

HardTechnical

39 practiced

Assess the pros and cons of automatically blocking PR merges for vulnerabilities above a CVSS threshold vs allowing merges and auto-creating prioritized remediation tickets. Consider developer productivity, attack window, context-aware exploitability, and false positives. Recommend a policy that balances security and velocity and describe an exception process.

Sample Answer

**Clarify scope & assumption**Assume CI/CD with automated SCA/DAST/SAST that emits CVSS scores, ticketing system, and developer SLAs. CVSS alone is an initial severity signal, not a complete exploitability verdict.

**Pros / Cons**

- Automatically block merges for CVSS ≥ threshold - Pros: - Immediate reduction of attack window for high-severity findings - Clear, enforceable policy; easy audit trail - Cons: - High developer friction; blocks on low-impact or non-exploitable issues - Increases context-switching and build queue contention - False positives or noise can cause developer workarounds (e.g., bypasses)

- Allow merges + auto-create prioritized remediation tickets - Pros: - Preserves developer velocity and CI throughput - Enables prioritized remediation workflows and batching - Easier to attach contextual triage data and assign ownership - Cons: - Longer attack window if critical findings are truly exploitable - Relies on triage discipline; tickets may languish without enforcement

**Context-aware factors**- Exploitability (Poc, exploit maturity), asset exposure (internet-facing vs internal), business-criticality, compensating controls (WAF, network segmentation).- Use additional telemetry (runtime detection, threat intel) to escalate.

**Recommended policy**- Hybrid, risk-based gating: - Block merges only for findings that meet ALL: CVSS ≥ 9.0 AND (confirmed exploitability OR internet-facing/privileged component). - For CVSS 7.0–8.9: allow merge, auto-create high-priority remediation ticket with SLA (e.g., 7 days) and automatic escalation if not remediated. - For CVSS < 7.0: allow merge, create normal-priority tickets. - Integrate automated triage: attach proof-of-concept, affected component, exposure and suggested remediation to tickets. - Dashboard and weekly security-developer reviews to ensure SLAs met.

**Exception process**- Submit exception request via ticket with: business justification, compensating controls, risk acceptance duration, and mitigation plan.- Security review board (security architect + engineering lead + product owner) approves time-bound exceptions (max 30 days) with monitoring requirements; renewals require stronger justification.- Maintain exception registry and quarterly audits.

This balances reducing real attack windows while minimizing developer disruption through context-aware enforcement, SLAs, and formal exceptions.

Unlock Full Question Bank

Get access to hundreds of DevSecOps and Secure SDLC interview questions and detailed answers.

Join thousands of developers preparing for their dream job.