Design Security Code Scanning - System Design | WinJob

What we are designing

Interview prompt: Design Security Code Scanning—a multi-tenant DevSecOps platform integrating SAST, SCA, secret detection, and optional DAST hooks comparable to practices at Snyk, Veracode, and Checkmarx. The platform ingests repository events, runs static analysis and dependency checks in isolated workers, normalizes results, deduplicates findings, and enforces merge policies without drowning engineers in noise.

Why this question matters

Enterprises have thousands of microservices; manual review cannot scale. A credible design must cover: secure handling of proprietary source, incremental analysis for fast PR feedback, cross-engine normalization (SARIF/OCSF-like), risk-based prioritization beyond raw CVSS, and auditability for SOC2.

Core user journeys

Application security engineer authors policy bundles (severity gates, grace periods, license deny lists) and monitors SLA dashboards.

Developer sees PR checks with diff-scoped findings and remediation guidance.

Platform SRE scales worker pools when queue lag exceeds SLO.

Real-world anchors

Snyk popularized developer-first SCA in CI; Veracode emphasizes deep SAST sandboxes; Checkmarx focuses on enterprise policy hierarchies. Your interview answer should unify these into one control/data plane story.

javaOne Dark Pro

1 public record ScanJob(String tenantId, String repoId, String commitSha, ScanKind kind) {}

pythonOne Dark Pro

1 @dataclass
2 class ScanJob:
3     tenant_id: str
4     repo_id: str
5     commit_sha: str
6     kind: str  # SAST | SCA | SECRETS

typescriptOne Dark Pro

1 export interface ScanJob {
2   tenantId: string;
3   repoId: string;
4   commitSha: string;
5   kind: "SAST" | "SCA" | "SECRETS";
6 }

Why interviewers care

Security Code Scanning interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Security Code Scanning Platform that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Unify SAST, SCA, and secret scanning behind one finding model
•PR-time scans must finish in minutes, not batch overnight only
•Never persist credentials or tokens inside finding records

1	@dataclass
2	class ScanJob:
3	tenant_id: str
4	repo_id: str
5	commit_sha: str
6	kind: str # SAST \| SCA \| SECRETS

1	export interface ScanJob {
2	tenantId: string;
3	repoId: string;
4	commitSha: string;
5	kind: "SAST" \| "SCA" \| "SECRETS";
6	}