Secure SDLC Study Portal

A: SAST (Static Application Security Testing) analyzes source code, bytecode, or binaries statically — without running the app — so it sees all code paths and runs early (IDE/PR/CI), but lacks runtime context and tends to produce more false positives (white-box). DAST (Dynamic) tests the running application from the outside by sending real requests, so it catches configuration, authentication, and runtime issues SAST can't see and has fewer false positives, but it only covers what it can reach and runs late (staging). They're complementary; IAST instruments the running app from the inside to combine both.

A: Because the flaw is the absence of a control or trust boundary in the design — there is no incorrect line of code to fix. If a money-transfer endpoint was never specified to require a second factor or a rate limit, the code "works as designed"; the design is wrong. Fixing it requires changing the design/requirements (threat modeling, abuse cases, adding the missing control), not editing a buggy statement.

A: STRIDE is a threat-modeling mnemonic enumerating six threat categories: Spoofing (violates authentication), Tampering (integrity), Repudiation (non-repudiation/audit), Information disclosure (confidentiality), Denial of service (availability), and Elevation of privilege (authorization). You walk each element of a data-flow diagram and ask which STRIDE threats apply.

A: A Software Bill of Materials is a machine-readable inventory (SPDX or CycloneDX) of every component and version in a build, including transitive dependencies. When a new critical CVE drops (e.g., Log4Shell), an SBOM lets you answer "are we affected, and exactly where?" in minutes rather than scrambling for weeks — it's the inventory that makes incident response and SCA actionable.

A: Server-Side Request Forgery tricks your server into making a request to an attacker-chosen destination (typically via a feature that fetches a user-supplied URL). 169.254.169.254 is the cloud instance metadata endpoint (IMDS); from inside the host it can return temporary IAM credentials and secrets. An SSRF that reaches it can exfiltrate cloud credentials — the core of the 2019 Capital One breach. Blocking it (and requiring IMDSv2) is essential.

A: Deny-lists are bypassed by alternate IP encodings (hex/decimal/octal), DNS that resolves to internal addresses, DNS rebinding (TOCTOU), open redirects, and IPv6 forms. An allow-list of explicitly permitted hosts/schemes is "deny by default," so unknown destinations are blocked regardless of encoding tricks. Best practice combines an allow-list with validating the resolved IP against private/link-local ranges, forbidding cross-host redirects, and an egress firewall.

A: It's the canonical software-supply-chain / software-integrity failure (A08): attackers compromised SolarWinds' build pipeline and inserted the SUNBURST backdoor into legitimately signed Orion updates, which auto-deployed to ~18,000 customers. Defenses: treat CI/CD as a production-grade, least-privilege, audited system; sign artifacts and verify provenance (SLSA, Sigstore/cosign); require reviewed/signed changes to build config; and verify update signatures before applying.

A: Moving security activities earlier in the lifecycle — into design, the developer's IDE, and the pull request — instead of only at a late pentest or in production. The motivation is cost and speed: a flaw is cheapest to fix the moment it's introduced. Concretely it means pre-commit secret scans, SAST/SCA on every PR, and automated policy gates that fail the build on high-severity findings.

A: A lockfile pins exact dependency versions (including transitive ones) so a build is reproducible, and integrity hashes ensure each fetched artifact byte-matches what was reviewed. Without it, a floating version (latest/^1.x) can silently pull a newly-published malicious release of a transitive dependency; with pinned versions + hashes, a tampered or swapped artifact is rejected.

A: Default/unchanged credentials, verbose error pages leaking stack traces and framework versions in production, publicly-open cloud storage and over-broad IAM/security groups, unnecessary features left enabled (sample apps, debug endpoints, directory listing, unused ports), and missing hardening — absent security headers (CSP/HSTS/X-Content-Type-Options/frame-ancestors) and permissive CORS. They're driven by configuration drift and a lack of a hardened, repeatable baseline.

A: Because you didn't choose them and often don't know they're there — the libraries you import pull in dozens more, and the bulk of real-world vulnerable-component exposure lives several levels deep (Log4Shell reached most victims transitively). Manually "reviewing the libraries we import" misses them; you need SCA over the full resolved dependency tree plus an SBOM to see and patch them.

A: Secure by default means the out-of-the-box configuration is the safe one (deny by default, encryption on, dangerous flags off), so doing nothing special still yields a secure system and insecurity requires a deliberate opt-in. Defense in depth means layering multiple independent controls (e.g., parameterized queries + least-privilege DB account + WAF) so that no single missed or broken control is fatal — the system fails closed and the next layer contains the damage.

A: IAST (Interactive AST) runs an instrumentation agent inside the running application during tests, so it correlates real request traffic with the exact executing code. That gives it DAST's runtime accuracy (real config/auth behavior, low false positives) plus SAST's code-level precision (it can point at the vulnerable line), at the cost of needing the app instrumented and exercised by tests.

A: It covers insufficient visibility — not logging auth events, access-control failures, or high-value actions; logs without enough context; logs not centralized, alerted on, or retained; and no incident-response plan. It matters because prevention is never perfect: without detection-and-response you can't see an attack in progress or investigate a breach. Log security events (with correlation IDs, never secrets/PII), centralize to a SIEM, alert on anomalies, and rehearse response.

A: Secret scanning runs earliest — pre-commit hooks and PRs (catch keys before they're committed). SAST and SCA run on every pull request and in CI (fast, white-box, before merge). The build then produces a signed artifact + SBOM. DAST (and IAST) run later against a deployed staging/pre-prod environment. A policy gate fails the build on high-severity findings, then deployment is followed by continuous runtime monitoring.