Secure Code and Supply Chain

At the Staff+ level, you should make it hard to make insecure decisions across teams.

Most security incidents are actually the result of the same small set of repeatable mistakes.

According to the Pareto principle, 80% of risk comes from 20% of issues. Fixing those few and automating checks in CI/CD eliminates the majority of real-world security incidents—with minimal overhead.

In this lesson, we’re applying the Pareto principle to cover the most high-leverage security risks you should be prepared to counter.

We’ll break it down across two planes:

• Application code

• Software supply chain

Let’s dig in!

App-level security

These risks live inside your code and features and are the root cause of most real-world breaches.

We’ll cover 6 for our 80/20:

1. Broken access control

Always enforce on the server, never the UI.

• “Request export” → owners can export their own data.

• “Export all” → only admins allowed.

• Log every allow/deny with who/what/why and a trace ID.

Now you can explain any export later without digging through Slack threads.

2. SQL injection

Never build SQL with string concatenation.

• Use parameterized queries (db.query(sql, params)).

• Wrap your DB client so this is the only allowed path.

In exports, pass date range, tenant filters, and included columns as parameters, not string-built SQL.

3. Misconfigurations

Debug mode in production equals an attacker starter kit.

• Exposes error pages, stack traces, file paths, env vars, and admin endpoints.

• In prod: DEBUG=false, production config loaded, no hot-reload, no public consoles.

• Add a startup/CI check: fail the build if debug is on.

4. Secrets leaks

Don’t ever hardcode keys.

• Store in Key Management Service (KMS) or your cloud’s secret manager.

• Turn on secret scanning in pre-commit hooks + CI.

• Fail builds if a key is committed.

Don’t log secrets (yes, even in dev).

5. XSS and CSRF

Web basics that still matter:

• Escape outputs.

• Add CSRF tokens on forms.

• Use SameSite cookies.

• Set CSP (Content Security Policy) → only load code from your domain.

• Set HSTS (HTTP Strict Transport Security) → force HTTPS.

• Add X-Content-Type-Options: no-sniff.

In the export form, the POST request includes a CSRF token.

6. SSRF (Server-side request forgery)

Don’t let attackers trick your server into making requests.

• Block all outbound internet calls by default.

• Allowlist only what the service actually needs (storage, email).

• Block access to the cloud metadata address unless proxied.

Supply chain security

These threats live outside your code but can be just as dangerous.

We’ll cover 5 for our 80/20:

1. Vulnerable dependencies (CVEs)

• Scan all dependencies for known vulnerabilities (CVEs).

• Block merges if a critical CVE is found.

• Allow time-boxed exceptions (e.g., “ignore for 7 days while patching”).

You’re only as secure as your least-patched transitive dependency.

2. Insecure code patterns (SAST)

• Use Static Application Security Testing(SAST) to catch insecure logic in code (e.g., SQL injection, unsafe deserialization, missing auth).

• Integrate SAST tools into CI/CD.

• Fail builds on high-severity issues.

3. Exploitable behavior in prod (DAST)

• Use Dynamic Application Security Testing (DAST) to simulate attacks against your app (e.g., XSS, CSRF, and auth bypasses).

• Run DAST against a test/staging environment.

• Prioritize coverage of high-risk flows like login, exports, and admin features.

4. Secrets in the codebase

• Turn on secret scanning in pre-commit hooks and CI pipelines.

• Block commits that include API keys, credentials, or tokens.

• Use a KMS or cloud secret manager (e.g., AWS Secrets Manager, GCP Secret Manager).

5. Untracked software components

• Generate a Software Bill of Materials (SBOM) on every build.

• Store it with the artifact.

• When a new CVE drops, you can instantly answer: “Are we affected?”

SBOMs make incident response and compliance dramatically faster.

Shift-left

• In CI/CD, run SAST, dependency scan, secret scanning, and SBOM generation on every build.

• Update the pull request template with a short security checklist: access control test present, parameterized queries, CSPContent Security Policy/HSTS(HTTP Strict Transport Security, and CSRF handled.

PR template “must-haves”

• Access-control test: admin = allow, non-admin = deny for changed endpoints.

• Queries are parameterized (no string-built SQL).

• CSP + HSTS present (or covered by shared middleware).

• CSRF handled if there’s a cookie-based form.

Lock in the 80/20: server-side checks, parameterized queries, safe headers, and secret/dependency gates, so customer exports are safe by default and incidents stay boring.