Audit Logging, OWASP & Supply-Chain Security

Prove what happened, block the obvious, trust nothing you did not build

Three defenses that share a theme: prove what happened, block the obvious attacks, and trust nothing you did not build yourself.

Tamper-evident audit logging

An audit log records who did what to which resource when, and its whole value is that it cannot be quietly altered after the fact, including by an insider or an attacker who gained admin. So it must be separate from application logs and tamper-evident. Two techniques: hash chaining, where each entry stores a hash of its contents plus the previous entry's hash, so altering or removing any record breaks the chain and is detectable (the same idea a blockchain uses); and WORM storage (write-once-read-many, for example S3 Object Lock in compliance mode), which the storage layer itself refuses to overwrite or delete before a retention date. Combine them: write to WORM and chain the hashes.

What to capture per event: actor (user or service identity), action, resource, timestamp, source IP/session, and result (success or failure). Critically, keep PII and secrets out of the audit log. The log is widely readable for investigations and retained for years, so a password or SSN in it is a second breach waiting to happen. Log that user 123 viewed record 456, not the record's contents.

{ ts, actor, action, resource, source_ip, result, prev_hash, hash }
   -> append-only stream -> WORM store (S3 Object Lock) + hash chain

OWASP application defenses at the gateway

The OWASP API Security Top 10 is the standard checklist. The one interviewers hammer is BOLA (Broken Object Level Authorization), also called IDOR: the server returns object 456 because the URL asked for it, without checking that this caller owns 456. The fix is an authorization check on every object access, caller owns resource, never trusting an ID from the client. Others: input validation and parameterized queries (SQL injection), blocking SSRF (validate and allowlist any URL the server fetches, or an attacker pivots to your cloud metadata endpoint), and mass assignment (never bind a request body straight onto a model, or a user sets isAdmin=true). Centralize what you can at the API gateway (schema validation, rate limits, auth) but object-level authorization has to live in the service that knows ownership.

Interview nuance: BOLA is the number-one API risk precisely because it is invisible in a happy-path demo. It only appears when you ask "what if I change the ID in the URL to someone else's?" Say that sentence in an interview.

Supply-chain security

Most of your running code is dependencies, so you must secure what you did not write. SBOM (Software Bill of Materials, SPDX or CycloneDX) inventories every component so when the next Log4Shell drops you can answer "are we affected?" in minutes. SCA scanning flags known-vulnerable dependencies in CI. Artifact/image signing with Sigstore/cosign lets deploys verify an image was built by your pipeline, not swapped by an attacker, and SLSA provenance attests how and from what source an artifact was built.

Workload identity kills long-lived secrets. Instead of a static API key in an env var (which leaks, never rotates, and grants standing access), services get short-lived credentials from their identity. SPIFFE/SPIRE issues cryptographic service identities, and cloud OIDC federation lets a GitHub Actions job or a pod exchange its identity for a 15-minute cloud credential. No static key to steal.

Recap: make audit logs separate, append-only, hash-chained and WORM-stored with actor/action/resource but no PII; defend BOLA/injection/SSRF/mass-assignment (BOLA first); and secure the supply chain with SBOM, SCA, signing, SLSA provenance, and workload identity for short-lived creds.