DoorDash Security Architect Interview Preparation Guide (Mid-Level)

Scope & classification
Supply‑chain attacks fall into: code/package (public registries), artifact/binary delivery, build/deploy infrastructure, vendor/third‑party relationships, and insider threats.

Common vectors & concise architect controls

• Dependency confusion / namespace hijack (public registry vs private)

  • Control: Enforce private package registries, namespace locking, and DNS/registry allow‑listing; require SBOMs and package signing (e.g., Sigstore).

• Typosquatting packages

  • Control: CI policy to validate dependencies against approved manifests and use checksum/pinning; integrate malware scan on fetch and alert on unknown/low‑reputation packages.

• Malicious updates (compromised upstream releases)

  • Control: Require artifact signing and verify signatures in CI/CD; maintain internal mirrors and delayed canary deployment with behavioral monitoring.

• Compromised CI/CD (pipeline takeover or credential theft)

  • Control: Segregate build rights, enforce least privilege for CI agents, rotate credentials via ephemeral secrets, enable pipeline integrity (signed builds), and monitor pipeline logs/attestations.

• Compromised vendor employees / third‑party compromise

  • Control: Apply contractually required security assessments, least‑privilege API credentials, network segmentation, and continuous vendor telemetry/attestation (audit logs, SOC reports).

• Malicious containers/images from registry

  • Control: Use trusted registries, image signing (Notary/rekor), automated SBOM/scan during pull, runtime image allow‑listing with immutable tags.

• Hardware/firmware supply risk

  • Control: Demand provenance, firmware signing, hardware root of trust, and risk‑based procurement with vendor security assessments.

Operational enablers

• Enforce SBOM, artifact signing, runtime detection, telemetry/alerting, and regular threat modeling for third‑party integrations.

Direct answer

For a large-scale application, passwords should never be stored in any reversible or fast-to-compute form; they should be hashed with a modern, deliberately slow password-hashing algorithm, Argon2id (the current OWASP-recommended default) or bcrypt as a widely-supported alternative, combined with a unique, randomly generated salt per user so identical passwords never produce identical stored values, and tuned cost parameters that make each individual guess expensive enough to make large-scale offline cracking impractical even after a full database leak. A pepper (a secret value held outside the database, in application configuration or a secrets manager) adds a second layer that survives a database-only leak. The remaining, equally important half of the design is operational: a migration path that can move users off a weaker legacy hash without forcing a mass password reset, rate limiting on login attempts, monitoring for credential-stuffing patterns, and being honest about the user experience cost of a slow, secure hash.

Structured elaboration

Algorithm selection. Argon2id is the current recommended default: it is a memory-hard function, meaning it deliberately requires a configurable amount of RAM per hash computation, not just CPU time, which specifically defeats the massively parallel cracking hardware (GPUs, ASICs) that made older, memory-light algorithms crackable at enormous scale. bcrypt is an older but still acceptable and extremely widely deployed alternative, CPU-hard but not memory-hard, and remains a reasonable choice where Argon2 tooling is not yet available in a given language ecosystem. Both are deliberately slow by design, which is the entire point: a login check that takes 100 to 300 milliseconds is imperceptible to a real user logging in once, but the same cost multiplied across billions of guess attempts makes offline brute-forcing of a leaked hash database computationally expensive rather than trivial. Fast general-purpose hashes (MD5, SHA-256 used alone) must never be used for password storage, since their entire design goal, being fast, is the opposite of what password storage needs.

Per-user salts. A salt is a random value generated uniquely per user and stored alongside the hash (it does not need to be secret). Its purpose is specifically to defeat precomputed lookup tables (rainbow tables) and to ensure that two users with the same password produce completely different stored hashes, so a leak does not reveal "these accounts share a password" as a free signal, and an attacker cannot precompute a single table of common-password hashes that works against every account in the database at once. Modern password-hashing libraries (Argon2 and bcrypt implementations) generate and store the salt automatically as part of the resulting hash string, so this is rarely something an implementation has to build by hand.

Optional peppers. Unlike a salt, a pepper is a secret value, typically a single application-wide secret (or one of a small rotating set) held outside the database entirely, in application configuration, an environment variable, or a secrets manager. Its purpose is to add protection specifically against a database-only leak: an attacker who exfiltrates the password table alone (via a SQL injection vulnerability, an exposed backup, a misconfigured replica) still lacks the pepper, and cannot verify or crack the hashes without it, whereas an attacker who compromises the application server itself (and can therefore read the pepper too) is not helped by it. A pepper is a defense-in-depth layer on top of a properly salted hash, not a replacement for one.

Cost parameters. Both Argon2 and bcrypt expose tunable cost parameters (Argon2: memory size, iteration count, and parallelism; bcrypt: a work factor controlling the number of internal rounds) that should be set as high as the application's actual login-latency budget and server capacity allow, not left at a library default that may be outdated. The right approach is periodic re-benchmarking against current hardware (as attacker hardware and defender server hardware both improve over time, a cost parameter set once at launch quietly becomes weaker relative to modern cracking capability) and choosing the highest cost setting that keeps login latency within an acceptable, typically sub-second, user-facing budget.

Migration strategy for legacy hashes. This is the senior wrinkle in an otherwise well-understood staple: an application that currently stores passwords with a weaker legacy scheme (an old bcrypt work factor, or worse, an unsalted fast hash from years ago) cannot simply re-hash every stored password at once, since the plaintext is, by design, never available after the original hash was stored. The standard approach is rehash-on-login: the first time a user successfully authenticates after the migration begins, verify their password against the legacy hash as before, and if it succeeds, immediately re-hash the now-known-correct plaintext with the new algorithm and cost parameters and replace the stored value, all inside that single authenticated request. Users who log in regularly migrate transparently and gradually; users who never log in again keep their weaker hash indefinitely, which is an acceptable, bounded residual risk (their credential was never actively re-exposed, it simply was not upgraded), rather than the disruptive alternative of forcing every user to reset their password immediately, which causes real support load and account-abandonment.

Operational practices. Password hashing strength alone does not address every risk: rate limiting on login attempts (per-account and per-source-IP, with backoff and lockout thresholds) is necessary because a strong hash slows offline cracking of a leaked database but does nothing to stop a live, online guessing attack against the login endpoint itself, which needs its own defense. Monitoring should track failed-login-attempt patterns (spikes against a single account, or the same password tried across many accounts, a strong credential-stuffing signal) and alert distinctly from ordinary user error. The user-experience trade-off of a deliberately slow hash is real but small at the individual-request scale (a few hundred milliseconds added to a login that happens infrequently per user) and should be weighed against server capacity at peak login volume (a cost parameter tuned for security alone, without regard to concurrent login volume during, say, a Monday-morning traffic spike, can itself become an availability problem, which is why benchmarking cost parameters against realistic peak load, not just security ideal, matters).

Worked example

The rehash-on-login migration pattern, shown structurally (illustrative, not an executed benchmark):

def verify_and_migrate(user, submitted_password):
    if user.hash_algorithm == "legacy_sha256_unsalted":
        if legacy_verify(submitted_password, user.stored_hash):
            # Correct password now known in plaintext for this one request only;
            # immediately re-hash with the current algorithm and discard the plaintext.
            user.stored_hash = argon2id_hash(submitted_password)
            user.hash_algorithm = "argon2id"
            save(user)
            return True
        return False
    elif user.hash_algorithm == "argon2id":
        return argon2id_verify(submitted_password, user.stored_hash)

Trace this against a concrete population: assume 1,000,000 accounts, of which 600,000 log in at least once during the three months after migration begins. Each of those 600,000 accounts transparently upgrades to Argon2id the moment they authenticate, with no visible change to the user beyond the same login flow. The remaining 400,000 dormant accounts keep the legacy hash until they next log in (which may be never, if the account has been abandoned) or until a separate, explicit decision is made to force a reset for accounts that remain on the legacy scheme past some deadline. This is a deliberate, named trade-off: gradual, transparent migration for active users versus an unresolved tail of dormant accounts, rather than a single disruptive mass reset that would affect all 1,000,000 accounts' users regardless of whether their individual risk actually changed.

Trade-offs and pitfalls

• Choosing a fast general-purpose hash (unsalted or salted MD5/SHA-256) for password storage is the single most common and most damaging mistake; the entire design goal of a password hash is to be slow and memory-hard, the opposite of what those functions were built for.
• A pepper is not a substitute for proper salting and a slow algorithm; it defends against a narrower threat (database-only leak without application-server compromise) and should be treated as an additional layer, not the primary control.
• Cost parameters set once and never revisited quietly weaken over time as attacker hardware improves; periodic re-benchmarking against current hardware should be a scheduled operational task, not a one-time launch decision.
• A forced mass password reset after discovering a legacy-hash problem causes real, measurable user friction and support load, and the rehash-on-login pattern exists specifically to avoid that cost while still making steady, real progress on migrating the actual risk.
• Hashing strength does not substitute for rate limiting and monitoring; a perfectly chosen Argon2id configuration does nothing to stop a slow, patient, low-volume online guessing attack against the live login endpoint, which is a distinct threat requiring its own defense.

Direct answer

Psychological safety, in a mentoring relationship, is a mentee's confidence that they can ask a question, admit a mistake, or push back on something without it costing them standing or opportunity. It's built through small, consistent moments early on, and it's genuinely tested the first time the mentee takes a visible risk and sees how you respond.

Concrete early actions

• Name failure modes yourself first. Mentioning a mistake you made in a similar situation signals that admitting error is normal here, not a one-way expectation.
• Model uncertainty openly. Say "I don't know, let's find out" instead of bluffing, so not-knowing reads as acceptable.
• Treat early mistakes as expected, not exceptional. React to a mistake by focusing on the fix and what it reveals, not on assigning blame.
• Be consistent between casual moments and anything formal. If private conversations are open but a formal review contradicts them, trust breaks immediately.
• Give credit publicly, give hard feedback privately. This is the pattern most people are watching for even if they never say so.
• Agree explicitly that disagreement is welcome, and actually respond well the first time it happens.

Worked example

Early in a relationship, a mentee admitted they'd made a mistake that caused some rework. The response focused entirely on understanding what happened and fixing it, walking through the reasoning openly rather than assigning blame, and treating it as a useful, expected part of learning. In the sessions that followed, the mentee started surfacing problems earlier and asking more pointed questions, rather than waiting until something couldn't be hidden.

Trade-offs and pitfalls

A common mistake is treating psychological safety as a one-time opening statement ("feel free to ask me anything") rather than an ongoing pattern that has to survive contact with a real mistake. The mentee will judge safety retrospectively, based on what actually happened the first time they took a risk, not on what was said at the start. It's also worth not confusing psychological safety with lowered standards: it's about how failure is handled and discussed, not about removing accountability for the work.

Situation
As a security architect I inherited an environment with secrets spread across repos, VMs, and cloud services. The risk and operational toil prompted me to learn HashiCorp Vault as a centralized secrets solution.

Task
Deliver a production-ready Vault design and proof-of-concept (PoC) integrated with our CI/CD pipeline within 6 weeks.

Action

• Week 1–2: Read Vault official docs, HashiCorp Learn courses, and several GitHub PoCs.
• Week 3: Hands-on labs in a sandbox (Kubernetes + Vault Helm chart), wrote automation scripts.
• Ongoing: Weekly mentor sessions with our SRE lead and one security engineer for pair troubleshooting.

Result / Concrete change
Rolled out a phased architecture: Vault cluster behind ALB, Consul storage, AppRole auth for CI, dynamic database credentials. Replaced hardcoded secrets in 25 repos, automated credential rotation, reduced time-to-rotate from days to minutes, and lowered audit findings for secret exposure.

Reflection
Next time I’d run an early stakeholder workshop and a smaller pilot with measurable KPIs (time-to-rotate, number of secrets onboarded) to accelerate adoption and surface org constraints sooner.

Validating that a build is genuinely free of a backdoor from a prior release, when the attacker may have modified source subtly, means the verification has to be independent of the same build process that might have been compromised in the first place, since asking the compromised system to vouch for itself proves nothing.

Reproducible builds as the core technique

A reproducible build means the exact same source, built with the exact same toolchain and inputs, produces a byte-for-byte identical output regardless of who or what performs the build; if a second, independently-controlled build environment (ideally maintained by a different team or even a different organization entirely) produces a DIFFERENT output than the officially-released artifact from the same claimed source, that mismatch is direct evidence something was injected during the official build that isn't visible in the source itself, exactly the SolarWinds SUNBURST pattern where the backdoor lived in the build process, not the committed source.

Artifact signing and dependency provenance

Signing alone doesn't answer this question by itself, since a compromised build system can still sign whatever it produces with a legitimate key it has access to; what signing DOES give you is a verifiable link between a specific build event and a specific output, which becomes useful once you're independently reproducing that build and comparing. Dependency provenance (verifying every dependency pulled in during the build itself came from its expected, trusted source rather than a suspiciously substituted alternative) closes a related but distinct gap: even a reproducible build process can produce a backdoored output if one of its declared inputs was itself quietly swapped.

Code review and runtime attestation

A manual code review, focused specifically on the diff between the suspect release and the last confirmed-clean one, is a useful complementary check but not sufficient alone, since a sufficiently subtle backdoor (inserted at the build-toolchain level rather than in application source, as SUNBURST was) may not be visible in a source-level diff at all. Runtime attestation (verifying the running artifact's measured hash against an expected, known-good value, ideally using a hardware root of trust) extends this verification into production, catching a case where the artifact that was built cleanly gets swapped for something else after the fact, closer to deployment.

Trade-offs

Reproducible builds are the single most direct answer to this specific question (a backdoor invisible in source but present in the build process WILL show up as a build-output mismatch), but achieving true reproducibility across a full toolchain (compiler versions, embedded timestamps, non-deterministic build steps) is a genuine, ongoing engineering investment; a codebase that hasn't invested in reproducibility can still get partial confidence from independent code review and signed provenance, but neither of those alone closes the specific SUNBURST-style gap the way an independently reproduced, byte-identical build does.

Direct answer

Describe a specific incident where you personally made a containment decision, the trade-off you consciously weighed (typically downtime or business disruption against preserving evidence or fully understanding scope), how you coordinated with other teams to reach and communicate that decision, and one concrete thing you changed afterward as a result.

Structured elaboration

The strongest version of this answer picks one real, specific incident rather than a generic composite, names the actual trade-off you weighed in the moment (not an abstract "I had to balance security and business needs"), and is honest about what you'd do differently with hindsight, which reads as far more credible than a story where every decision was obviously correct in retrospect.

Structure it as: the situation (what alerted you, how severe it looked at first), the specific containment decision you had to make and why it wasn't obvious, how you coordinated with other stakeholders (who did you loop in, and when), the result (what actually happened, including any part that didn't go perfectly), and what changed afterward in your own approach or your team's playbook.

Worked example

"I was the on-call analyst when an EDR alert flagged a suspicious process on a shared file server used by two different business units. My first instinct was to isolate the host immediately, but that would have disrupted both teams' access simultaneously, and initial evidence wasn't yet clear whether this was a real compromise or a false positive from a recently-deployed monitoring rule. I spent about ten minutes pulling corroborating evidence, process details, recent authentication logs, before deciding the pattern was credible enough to isolate. Rather than isolating unilaterally, I called the on-call lead for one of the two affected business units to give a two-minute warning before I acted, since an unannounced outage on a shared resource would have caused confusion and extra support tickets on top of the actual incident. The host turned out to be genuinely compromised, evidence was preserved cleanly since I'd captured process and network state before isolating, and the business disruption was limited to about 20 minutes rather than becoming a longer, confusing outage. Afterward, I proposed adding a specific step to our containment runbook: a quick stakeholder-notification call before isolating any shared, multi-team resource, which wasn't previously an explicit step."

Trade-offs and pitfalls

A common weak answer describes only the technical containment action without describing an actual decision or trade-off, which misses what this question is really probing: judgment under uncertainty, not just technical execution. Another weak pattern is describing a story where hindsight makes every choice look obviously correct, which reads as either an oversimplified retelling or a lack of genuine reflection on what was actually uncertain in the moment.

Overview (role context)
As a Security Architect I map each GDPR principle to architectural decisions, operational controls and governance so compliance is built-in rather than bolted on.

Lawfulness, fairness, transparency

• Architecture: Data classification + consent flags in identity/data models.
• Ops controls: Consent management, DPIA for new systems, logging of lawful basis.
• Governance: Policy for lawful bases, review cycle, legal/Privacy Officer sign-off.

Purpose limitation

• Architecture: Purpose-tag metadata, access control tied to purpose.
• Ops controls: Purpose-based access reviews, automated workflow enforcement.
• Governance: Data use registry, change approvals for new uses.

Data minimization

• Architecture: Minimize fields, use tokenization/derived data, default anonymization.
• Ops controls: Ingest validation, retention-based purging, least-privilege RBAC.
• Governance: Data minimization rules, onboarding checklist.

Accuracy

• Architecture: Source-of-truth references, editable user profiles with audit trails.
• Ops controls: Data quality monitoring, correction workflows, reconciliation jobs.
• Governance: SLA for accuracy, user rectification process.

Storage limitation

• Architecture: Tiered storage with retention labels and automated expiry.
• Ops controls: Retention enforcement, archival/secure deletion pipelines.
• Governance: Retention policies mapped to risk/regs, periodic audit.

Integrity and confidentiality

• Architecture: Encryption at rest/in transit, HSMs for keys, segmentation, DLP.
• Ops controls: MFA, IDS/IPS, patching, secure SDLC.
• Governance: Encryption/KM policies, incident response playbooks, regular pen tests.

Accountability

• Architecture: Audit trails, telemetry, Privacy-by-Design patterns.
• Ops controls: Reporting metrics, DPIAs, breach detection/notification processes.
• Governance: Roles (DPO), documentation, evidence for regulators, continuous compliance program.

This approach ensures GDPR principles directly shape design choices, daily operations and executive-level governance.

Direct answer

Don't force one team's cadence onto the other. Design a policy that separates what must be shared (the guardrails that protect everyone) from what can stay team-specific (how fast a given team is allowed to move within those guardrails), then negotiate the guardrails, not the cadence itself. That reframing turns "fast team vs. cautious team" into a joint design problem both sides can own.

Structured elaboration

1. Split invariant from flexible. List what truly must be uniform across teams (a working rollback path, a minimum test bar, an incident-response process) versus what can legitimately vary (deploy frequency, staging gate count, review depth). Most conflicts collapse once you see that only a small slice actually needs to be shared.
2. Reframe cadence as risk exposure. Ask each side what they're protecting (customer trust, an SLA, a compliance obligation) versus what they want (velocity). Convert both into measurable guardrails: blast radius limits (how much of the system or traffic a change could affect if it goes wrong), an automated rollback trigger (a rule that reverts the change automatically once a threshold is crossed, without waiting for a human to notice), a minimum observation window before a change is considered "safe."
3. Build a tiered policy, not a single rule. Changes that touch a small blast radius and have a fast, automatic rollback can move on the fast-moving team's cadence. Changes that touch shared, hard-to-reverse surfaces get the slower team's gates, regardless of which team wrote the change. The tiering criteria, not the team identity, decides the process.
4. Add an explicit exception path. Either side can request a deviation (ship something in a higher tier faster, or hold something in a lower tier longer) with a documented reason and a named approver, so departures from the policy are visible instead of quiet workarounds.
5. Time-box a trial and revisit with real data. Don't debate the policy hypothetically forever. Run it for a fixed period, then bring incident counts and delivery-time data back to the table instead of re-litigating the original positions.

The same negotiation pattern applies beyond deploy-frequency disputes: whenever two functions have structurally different operating rhythms, the fix is a shared cadence at the boundary, not a winner. As a concrete cross-team cadence clash from the machine-learning world: a feature store (the shared system that stores and serves the data used to train and run machine-learning models) team can only refresh labels every two weeks, while the product team needs weekly model retraining (rerunning the training process on newer data so the model's predictions stay current). That isn't a risk-tolerance disagreement at all. It's a hard technical constraint on one side meeting a business cadence need on the other, and it gets negotiated the same way: agree what must move on the constrained cadence (the underlying label refresh) versus what can be decoupled (the product team retrains weekly on the two most recent completed label batches, accepting known staleness, rather than blocking on a refresh that can't happen faster).

Worked example

Team A ships to production many times a day behind feature flags. Team B owns a regulated, customer-facing billing surface and wants a weekly release train. Instead of debating "how often should we deploy," the negotiated policy ties process to blast radius: any change gated behind a flag to less than 1% of traffic can auto-promote if the error rate stays under 2x the pre-change baseline for a 30-minute observation window (a policy parameter both sides agreed to, not a claimed result). Changes that touch the billing ledger directly, regardless of author, require the slower manual review and a scheduled release window. Team A keeps most of its velocity because most of its changes are low blast radius; Team B keeps its protection because the surface it cares about is gated the same way no matter who wrote the change.

For the cadence-mismatch variant: the feature store team commits to publishing a refreshed label snapshot every two weeks, on a fixed schedule the product team can plan around. The product team's weekly retraining job consumes the most recent snapshot plus a lightweight, clearly-labeled interim signal for the intervening week, rather than either side pretending the refresh can happen weekly or the product team silently retraining on stale labels without acknowledging it.

Trade-offs & pitfalls

• Pitfall: writing a single global policy. It's either too loose for the regulated team or too strict for the fast-moving one, and both sides end up circumventing it.
• Pitfall: treating this as a one-time meeting. Without a scheduled revisit, the policy calcifies around the political balance of the original conversation instead of actual incident/velocity data.
• Pitfall: hiding exceptions. If deviations aren't logged and visible, the "shared" part of the policy erodes silently and trust breaks down the next time there's an incident.
• Senior differentiator: designing the guardrail so it's parameterized by risk (or, in the cadence case, by the actual constraint) rather than by team identity. That's what lets both sides keep their operating model instead of one side losing the negotiation.

Direct answer
Signs pointing toward a security incident rather than a purely operational one include unexplained privilege or permission changes, authentication failures or account lockouts clustering in an unusual pattern, traffic or data-access patterns that look like exfiltration rather than normal load, and any sign of unauthorized file or configuration changes that nobody on the team made. Once you suspect any of these, the biggest change is that you stop trying to 'just fix it': you preserve evidence instead of immediately remediating, and you loop in a security responder rather than continuing to triage it as a routine outage.

Structured elaboration

• Signals that lean operational: the timing correlates with a known deploy or infrastructure change, the failure pattern matches a resource exhaustion or a known dependency issue, and the behavior is explainable by something the team did on purpose.
• Signals that lean security: access or configuration changes nobody recognizes, authentication anomalies (a spike in failed logins, logins from unusual locations, tokens being used in ways that don't match normal patterns), data being read or moved in volumes or patterns that don't match normal usage, or any indicator resembling a known attack pattern (credential stuffing, privilege escalation, lateral movement).
• What changes once you suspect it. You stop applying your normal 'fix it fast' instincts on the affected system, because touching it (restarting a process, wiping a disk, rotating credentials without first documenting state) can destroy evidence a security investigation needs. You loop in whoever owns security response, and from that point the deep investigation, containment technique, and evidence-handling discipline live with that team rather than being improvised by whoever happened to be on call.
• Who to involve: the security on-call or incident response function, as early as suspicion arises, not after you've already tried to resolve it yourself.

Worked example
A service starts throwing errors and the on-call engineer initially assumes it's a bad deploy, since that's the most common cause. But checking recent deploys shows nothing changed, and instead they notice a spike in failed authentication attempts against an admin endpoint in the minutes before the errors started, followed by a permissions change on a service account that nobody on the team made. That combination (no correlated deploy, authentication anomaly, unexplained permission change) is the tell that this isn't a routine outage; the engineer stops attempting further remediation, preserves the current state (avoids restarting the affected service, which could wipe useful logs), and escalates to the security team rather than continuing to debug it as an availability problem.

Trade-offs and pitfalls
The main risk under pressure is dismissing security signals too quickly because restoring service feels more urgent, which can mean actively destroying evidence (restarting a compromised host, deleting suspicious files 'to clean up') before anyone with security expertise has looked at it. The opposite risk is over-escalating every anomaly as a security incident, which burns the security team's time and can create alert fatigue that makes real security incidents harder to distinguish from noise; the right calibration is a small, well-understood set of signals (like the ones above) rather than a vague sense that 'something feels off.'

Secure-by-Design Architecture Review Checklist

1. Design Principles (must be justified)

• Least privilege for components and APIs
• Defense in depth (network, app, data layers)
• Fail-safe defaults and secure defaults (TLS, secure cookies)
• Separation of duties and multi-tenancy isolation
• Immutable infrastructure and reproducible builds

2. Mandatory Controls

• Strong authentication (OIDC/OAuth2, MFA) and centralized IAM
• Authorization model (RBAC/ABAC) with fine-grained policies
• Transport & storage encryption (TLS 1.2+/AES-256 or KMS)
• Secrets management (vault, no plaintext in repos)
• Secure logging/central SIEM with tamper-evident storage
• Runtime protection (WAF, EDR, container runtime scanning)
• CI/CD gates: SAST, DAST, dependency scanning, SBOM

3. Threat-Modeling Triggers

• New external-facing API or B2B integration
• Privileged access paths, admin consoles, or service accounts
• Multi-tenant data handling or cross-customer processing
• Use of third-party SaaS/SDKs or custom crypto
• High-value data flows (PII, financial, IP)

4. Privacy & Compliance

• Data classification and retention mapped to service flows
• Data minimization and purpose-limiting controls
• DPIA required for sensitive/high-risk personal data processing
• Regulatory checkboxes: GDPR, HIPAA, PCI-DSS applicability matrix
• Consent, data subject rights, and cross-border transfer controls

5. Developer Deliverables (required before approval)

• Threat model (STRIDE/attack surface) and mitigations matrix
• Secure architecture diagram with trust boundaries and data flow
• IAM policy proposals and least-privilege IAM roles
• SBOM, dependency risk report, and SCA results
• Test plan: SAST/DAST/pen-test schedule and remediation SLAs
• Runbooks for incident response & key rotation procedures

6. Common Findings & Remediations

• Finding: Secrets in source or container images → Remediation: Move to vault, rotate, add CI scan block.
• Finding: Missing authentication on internal API → Remediation: Add mTLS or token-based auth and enforce in gateway.
• Finding: Broad IAM permissions (wildcard roles) → Remediation: Define scoped roles, apply IAM policy simulator.
• Finding: No data retention policy for PII → Remediation: Add retention rules, purge/archival automation, update privacy notice.
• Finding: Unvalidated third‑party SDK → Remediation: Replace or isolate with wrapper, add dependency monitoring and compensating controls.

Use this checklist as gating criteria: critical items must be addressed before production; high-risk items require compensating controls and a remediation timeline.