Hands-on Lab

This is the hands-on portion of the master class. Everything up to now has been framing; here you actually drive an AI security tool against real code, decide which of its findings deserve your attention, and ship a fix. The deliverable is a single pull request containing at least one security fix that you understand well enough to explain to a skeptical reviewer. Working in pairs is encouraged — one person drives the tool while the other plays critic, then you swap.

If you have not already, skim Trinetra and The Autonomous SOC first, and keep the Attack Surface Maps handy — when Trinetra reports a finding, locating the equivalent point on the relevant map is a fast way to reason about how serious it really is. The lab is the place where those ideas stop being slides and become muscle memory.

Before you start

You will need three things:

• A modern browser and a GitHub (or compatible) account you can sign in to.
• A repository you are allowed to open pull requests against. For this lab, use a deliberately vulnerable demo repo so there is something genuine to find — see Choosing a target repo below.
• Access to Trinetra, the “Security for Builders” platform you will be driving throughout.

Rules of engagement

Only analyze code you own or are explicitly authorized to test. Run any proposed fix against a fork or a feature branch, never directly into a production main. This is the same authorization principle the lecture hammered on — now applied to your own keyboard. Scanning a codebase you do not control, even with good intentions, is the line between security research and a problem.

Choosing a target repo

The whole point is to encounter real vulnerabilities in a setting where breaking things is the expected outcome. Good practice targets — intentionally vulnerable and safe to break — include:

• OWASP Juice Shop — a modern, deliberately insecure web application (JavaScript/Node). Broad coverage of the OWASP Top 10, and fun to attack.
• OWASP WebGoat — a teaching application full of classic flaws (Java).
• PyGoat — an intentionally vulnerable Django application (Python).
• Your own forked side project — often the most motivating option, because the findings are real and the fixes ship to something you actually care about.

Fork your chosen target into your own account first, so you can open pull requests freely without touching anyone else’s repository.

The lab

1. Connect the repository.

   In Trinetra, connect your Git provider and select the forked repository you prepared. When the authorization screen asks for access scopes, grant the minimum it needs to read the code and open a pull request — nothing more. Least privilege is not just advice you give other teams; it applies to the tools you adopt. A code-analysis tool rarely needs admin rights on your whole organization, and a habit of granting broad scopes “to be safe” is exactly how supply-chain exposure creeps in.

2. Run the analysis.

   Kick off a scan of the repository. While it runs, do something deliberately old-fashioned: predict out loud what you expect it to find. If you picked Juice Shop, you might bet on injection flaws and weak authentication; on your own project, maybe a leaked key you half-remember committing. Comparing your prediction against the actual results is half the learning — it surfaces both your blind spots and the tool’s.

3. Read the findings like an analyst, not a checklist.

   When results arrive, resist the urge to treat them as a to-do list to clear. For each finding, answer the three questions in the triage rubric: is it real, how bad is it, and do you genuinely understand the fix? A scanner produces signal and noise; your job is to tell them apart. The analyst who can confidently reject a false positive is more valuable than one who mechanically patches everything the tool flags.

4. Pick your battles.

   Do not try to fix everything. Choose one to three findings that are clearly real and clearly important, and ignore the rest for now. Depth of reasoning beats breadth of diffs: one fix you can defend in an interview is worth more than ten you applied on faith. A focused PR is also far easier for a reviewer to trust and merge.

5. Generate the fix and open the pull request.

   Have Trinetra propose fixes for the findings you selected and open a pull request with them. Treat that PR as a draft authored by an assistant, not a finished change — this is precisely the “human on the loop” model from The Autonomous SOC. The machine drafts; you decide.

6. Review the PR critically.

   Read the diff as though a fast but junior engineer wrote it, because in effect one did. Ask: Does the change actually remove the vulnerability, or merely move it? Does it alter behavior or risk breaking a feature? Is there a test that fails before the fix and passes after it — and if not, can you add one? Does the PR description describe the risk accurately? An AI-generated fix that “looks right” but silently changes an API response is worse than no fix at all.

7. Write a defensible PR description.

   Rewrite the PR body so it clearly states four things: the vulnerability, the risk if it ships unfixed, the fix you applied, and how you verified it. If you cannot write that paragraph confidently and in your own words, you are not finished reviewing — go back to step 6.

Two worked examples

These are illustrative — the exact findings you see will depend on your target repo and the state of the tooling — but they show the shape of good triage.

Example 1 — a hardcoded credential in a config file

Suppose the analysis flags a cloud access key or third-party API token committed in plaintext, for example an AWS_SECRET_ACCESS_KEY or a Stripe key sitting in config/settings.py or a checked-in .env.

Why it matters: anything in Git history is effectively public the moment the repo is shared or forked, and history is forever — deleting the line in a later commit does not remove it. A leaked key can be replayed to spin up infrastructure, read data, or rack up charges on your account.

What a fix looks like: remove the secret from the code, load it at runtime from an environment variable or a managed secret store (a secrets manager / vault), and rotate the key — assume the old value is already compromised. Add the file pattern to .gitignore so it cannot happen again. A PR that only deletes the line without rotating is not a real fix, and saying so in review is exactly the kind of judgment this lab is training.

Example 2 — a SQL injection from string concatenation

Suppose the tool flags a database query built by gluing user input directly into a SQL string, such as "SELECT * FROM users WHERE email = '" + email + "'".

Why it matters: an attacker controls part of the query, so input like ' OR '1'='1 can bypass authentication, dump entire tables, or in the worst case modify data. This is a textbook, high-severity flaw precisely because it is so easy to exploit and so damaging.

What a fix looks like: replace the concatenation with a parameterized query / prepared statement, where user input is passed as a bound parameter rather than spliced into the SQL text, so the database treats it strictly as data. In review, confirm the fix covers every tainted path into that query, not just the one line the scanner happened to point at.

Tip

For both examples, the highest-value move is the same: trace the untrusted input from where it enters the system to where it does damage. If you can describe that path, you can judge whether the fix truly closes it.

Triage rubric

Question	What you are looking for
Real?	A reachable path from untrusted input to a vulnerable sink. Reject false positives out loud.
Severity	Confidentiality/integrity/availability impact plus exploitability. A quick CVSS-style gut check: Low / Med / High / Crit.
Fix correctness	Closes the hole and preserves intended behavior. No new bug introduced.
Regression risk	Tests exist or are added; you understand the blast radius of the change.
Defensible	You can explain the whole finding and fix in three plain sentences.

See the glossary if any of these terms are unfamiliar.

What “done” looks like

• At least one pull request opened with a real, correct security fix.
• A PR description that names the vulnerability, the risk, the fix, and the verification.
• You can explain why the fix works — and name at least one finding you deliberately rejected, and why it was noise or out of scope.

Debrief

Bring it back to the themes of the class:

• How long did your find → fix → PR loop actually take? Set that against the minutes an AI-driven attacker needs to move from discovery to exploitation (see The Autonomous SOC). The asymmetry is the whole argument for tooling like this.
• Where did you, the human, add value the tool could not — rejecting a false positive, catching a behavior change, writing the test? That judgment is the job that survives the shift described in The Mythos.
• What would it take to run this continuously, on every commit, instead of once in a workshop? That is what “shifting left” means in practice.