Secure Coding, Fuzzing & AI-Written Code

#Start here: the basics in plain words

Every security bug in code comes down to the program trusting something it shouldn't. A web form field ends up inside a database query. A file length from the network is used without checking. A user ID in the URL is believed without asking "is this yours?". Secure coding is the set of habits that stop untrusted things from reaching dangerous places.

Two words make code review much easier:

1. A source is where untrusted data comes in: an HTTP request, a file upload, a message from a queue, an environment variable an attacker might set, the output of an AI model.
2. A sink is where data can do damage: a SQL query, a shell command, an HTML page, a file path, a deserialiser, a redirect.

A vulnerability is a path from a source to a sink with nothing safe in between. The four topics on this page attack that path from different angles:

Memory hook

"follow the data from source to sink". Every finding in a code review is a path where untrusted data reached something dangerous without being made safe.

#Secure Coding Practices

What is this?A short list of habits that remove whole classes of bugs, instead of fixing them one at a time. The best ones don't rely on developers remembering anything: they make the safe way the easy way.

Why it mattersMost serious application vulnerabilities (injection, broken access control, unsafe deserialisation, path traversal) are not exotic. They are the same few mistakes, repeated. An engineer who can name the habit that prevents each one, and spot its absence in a diff, is exactly what an AppSec interview is testing.

How it worksThe habits, each with the bug class it removes:

In practiceThe same feature written unsafely and safely (Python):

# Unsafe: user input becomes part of the SQL text, and nobody checks ownership
def get_invoice(request, invoice_id):
    return db.execute(f"SELECT * FROM invoices WHERE id = {invoice_id}")   # ← injection + IDOR

# Safe: input is a bound parameter, and the query itself enforces ownership
def get_invoice(request, invoice_id: int):
    row = db.execute(
        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",
        (invoice_id, request.user.id),                                    # ← data never becomes code
    ).fetchone()
    if row is None:
        raise NotFound()                                                  # ← same answer for "missing" and "not yours"
    return row

Security angleStatic analysis (SAST) tools such as Semgrep and CodeQL automate the source-to-sink search, but they produce false positives and miss logic bugs like missing ownership checks, which have no tell-tale dangerous function. That's why the strongest controls are structural: a framework where every route is authenticated by default, a data-access layer that always filters by tenant, an HTML template engine that always escapes.

📰

Real incident — Apple "goto fail" (CVE-2014-1266, 2014). One duplicated line, goto fail;, in Apple's TLS code made the program jump past the final signature check. Because the error variable still held "success", every connection was accepted, so anyone on the network could impersonate any HTTPS site to iOS and macOS users. Lesson: security-critical code needs tests that prove the "reject" path works, not only that good input is accepted. Compiler warnings for unreachable code and mandatory braces would also have caught it.

🎯

On the job. When reviewing a pull request, start from the sinks: grep the diff for query building, subprocess/exec, innerHTML/dangerouslySetInnerHTML, file paths built from input, deserialisers, redirects and outbound HTTP calls to URLs from input (SSRF). For each one, trace back to its source. For every new route or handler, ask two questions: who may call it, and where is the ownership check?

#Software Fuzzing

Last verified2026-10

What is this?Fuzzing is automated testing with garbage. A fuzzer generates huge numbers of slightly broken inputs (truncated files, giant lengths, odd bytes, unexpected field orders), feeds each one to the code, and records any input that makes it crash, hang or break a rule. A human tester might try fifty bad inputs. A fuzzer tries millions an hour.

Why it mattersFuzzers find the bugs nobody thought to test for, especially in code that parses complex input: file formats, network protocols, image and video decoders, compression, certificate parsers. Those are exactly the places attackers aim. By 2023, Google's OSS-Fuzz service, which fuzzes open-source projects continuously, had helped fix over 10,000 vulnerabilities and 36,000 bugs across about 1,000 projects.

How it worksModern fuzzers are coverage-guided: they watch which lines of code each input reaches and keep any input that reaches somewhere new, then mutate that one. The input pool slowly learns the shape of valid data and pushes deeper into the program.

In practiceA fuzz test in Go, built into the standard toolchain since Go 1.18 (2022):

func FuzzParseHeader(f *testing.F) {
    f.Add([]byte("Content-Length: 42\r\n"))       // seed corpus
    f.Fuzz(func(t *testing.T, data []byte) {
        h, err := ParseHeader(data)
        if err == nil && h.Length < 0 {
            t.Fatalf("negative length accepted: %q", data)   // a property, not just "don't crash"
        }
    })
}

$ go test -fuzz=FuzzParseHeader -fuzztime=10m
fuzz: elapsed: 41s, execs: 2914836 (71093/sec), new interesting: 37
--- FAIL: FuzzParseHeader
    negative length accepted: "Content-Length: -9223372036854775808\r\n"   ← the bug
    Failing input written to testdata/fuzz/FuzzParseHeader/7c1e...          ← now a permanent regression test

The same idea exists for other languages: libFuzzer and AFL++ for C/C++, cargo-fuzz for Rust, Atheris for Python, Jazzer for Java. For web APIs, schema-based fuzzers (e.g. Schemathesis, RESTler) generate requests from an OpenAPI description.

Security angleFuzzing finds what crashes or breaks a stated rule. It won't find a missing authorization check, because a request that wrongly succeeds doesn't crash anything, unless you write that rule as a property. Coverage also stalls behind checksums, magic numbers and encryption, so good harnesses bypass or fix those up. In CI, run a short fuzz job (minutes) on every pull request and long campaigns (hours or days) on a schedule, and always keep the corpus.

📰

Real incident — Heartbleed (CVE-2014-0160, 2014). OpenSSL trusted a length field in a "heartbeat" message and copied that many bytes back from memory, leaking up to 64 KB per request, including private keys and passwords. It was found independently by a Google researcher and by the security company Codenomicon, whose team was testing with its own fuzzing tools. Fuzzing with AddressSanitizer catches this bug class quickly, and Heartbleed is a key reason OSS-Fuzz was created two years later.

📰

Real incident — AI-written fuzz target finds an OpenSSL bug (CVE-2024-9143, 2024). Google's OSS-Fuzz team used a language model to write new fuzz harnesses for code that had none. One of them found an out-of-bounds memory write in OpenSSL, in code that had been fuzzed for years. Lesson: the bottleneck in fuzzing is usually harness coverage, not fuzzing time.

🎯

On the job. Ask "which of our code parses input from outside, and is any of it fuzzed?" The answer is usually "the file-upload parser, the custom protocol handler and the token decoder, and no". Start with one harness per parser and a 10-minute CI job. When a scanner or an advisory reports a parsing bug in a dependency, check whether the project is in OSS-Fuzz before trusting its quality.

#When AI Writes the Code

Last verified2026-10

What is this?Coding assistants (Claude Code, GitHub Copilot, Cursor and others) now write a large share of new code, from single-line completions to agents that make whole pull requests. The code usually compiles and often works. But the model doesn't know your threat model, your tenancy rules or which internal library is the approved one, and it is very good at producing code that looks reviewed.

Why it mattersThe security risks fall into three groups, and interviewers increasingly expect you to name all three:

How it worksThe practical rule: treat AI output as a contribution from a fast, well-read junior developer who has never seen your codebase and can be tricked by text it reads.

In practiceWhat a hallucinated dependency looks like in a pull request, and the check that catches it:

+ "dependencies": {
+   "express-session-validator": "^1.0.2"       ← plausible name; does it exist? who published it, when?

$ npm view express-session-validator time.created maintainers
time.created = '2026-09-28T03:12:44.000Z'          ← created 17 days ago
maintainers  = [ 'dev8812 <...>' ]                  ← one unknown maintainer: block until reviewed

Security angleControls that work in practice:

📰

Real incident — Amazon Q Developer extension (2025). An attacker got a change merged into the open-source repository of Amazon's Q Developer extension for VS Code that added a prompt instructing the AI agent to wipe local files and delete cloud resources. It shipped in version 1.84.0 before AWS pulled it; the instruction was reportedly malformed and didn't execute. Lesson: text aimed at an AI agent is code, and it needs the same review and release controls as code.

📰

Real incident — Nx "s1ngularity" npm compromise (2025). Malicious versions of the popular nx build tool were published to npm. Their install script looked for AI coding CLIs on the developer's machine (Claude Code, Gemini CLI, Amazon Q) and ran them with permission checks disabled, asking them to find secrets and crypto wallets, which were then uploaded to public GitHub repositories. Lesson: an AI agent installed on a laptop is a powerful tool any malware can borrow, so its permission prompts should never be bypassed by default.

🎯

On the job. In review, ask the author "why this library, and why this approach?". If they can't answer, the code isn't reviewed yet. Add a CI check for newly added dependencies (existence, age, maintainer count, install scripts). Put coding agents' tool permissions, sandbox and allowed commands into your security standards like any other privileged software.

#Security in a Fast-Moving Codebase

What is this?Many companies merge hundreds of pull requests a day and deploy continuously, and AI assistants make the volume grow further. A security team of five cannot review all of it. Security for a fast-moving codebase means deciding where human attention goes, and making everything else safe by default and checked automatically.

Why it mattersThe classic model ("security reviews before release") doesn't fit. Either it blocks delivery and gets bypassed, or it rubber-stamps. Interviewers ask "how would you secure a codebase that ships 50 times a day?" to see whether you think in systems (defaults, guardrails, telemetry) or in gatekeeping.

How it worksFour layers, from most to least scalable:

In practiceTwo small files that do most of the routing and guarding:

# .github/CODEOWNERS — changes here need a review from the security group
/src/auth/            @acme/appsec
/src/payments/        @acme/appsec
/infra/               @acme/platform-security
/.github/workflows/   @acme/platform-security       ← CI is production too

# test_routes_require_auth.py — fails the build if anyone adds an unauthenticated route
PUBLIC = {"/health", "/login", "/static"}
def test_every_route_requires_auth():
    for rule in app.url_map.iter_rules():
        view = app.view_functions[rule.endpoint]
        assert rule.rule in PUBLIC or getattr(view, "requires_auth", False), rule.rule   # ← invariant, not a review comment

Security angleThe failure modes are predictable: scanners so noisy that developers learn to click through them, exceptions granted once and never revisited, review fatigue that turns approvals into rubber stamps, and dependency auto-updates that pull in a compromised release within minutes of publication. Counter them by measuring false-positive rates and deleting rules that don't earn their place, giving exceptions an expiry date, keeping security-critical paths small and owned, and adding a short cooldown before auto-merging dependency updates (see the 7-day window).

🎯

On the job. When you join a fast-moving team, don't start by reviewing pull requests. Map where the dangerous code lives (auth, tenancy, payments, parsers, CI), put CODEOWNERS on it, find the two or three bug classes that keep recurring in incidents and bug bounty reports, and kill each with a paved road or an invariant test. Then tune CI rules until developers trust a red build.

Memory hook

"make the right way the easy way, check it automatically, and save humans for the risky 5%".