Lab: Find the secrets

Scan a deliberately insecure project with DL Sentinel, read what it finds, fix a leaked token, and adopt a baseline so only new problems fail. Then turn the same habits on your own computer: open ports, a download's checksum, and an export you might share.

Level: beginner · Time: 45 to 60 minutes · Before this: the six lessons of this track, or at least Scanning your code

What you need

• A Linux computer with DL Sentinel built from source and the sentinel alias set up. See Install DL Sentinel.
• A terminal.
• For part 3: ApiWorkbench with at least one collection or environment.

The sample project is tests/fixtures/vulnerable-app inside the dl-sentinel folder. It contains at least one planted problem for every scanner, and every credential in it is fake. It exists to be scanned, so it is a safe target. You will work on a copy, so the original stays as DL Sentinel's own tests expect it.

Part 1: Scan a vulnerable project

1. Make a practice copy. From inside the dl-sentinel folder:

   cp -r tests/fixtures/vulnerable-app ~/sentinel-lab
   cd ~/sentinel-lab
   ls -a

   Expected: files such as .env, Dockerfile, docker-compose.yml, openapi.yaml, package.json, and the folders config, contracts, k8s, src and terraform.

2. Scan everything.

   sentinel scan .

   Expected: a summary like this:

   secrets           7 findings
   dependencies      5 findings
   source            11 findings
   infra             18 findings
   api               8 findings
   smart-contract    7 findings
   
   Critical: 11
   High:     28
   Medium:   6
   Low:      4
   Info:     7
   
   Scan completed.

   The exact numbers can change between DL Sentinel versions. What matters is that every scanner found something.

3. Check the exit code.

   echo $?

   Expected: 1. There are findings at a failing severity (critical or high), so a CI job running this scan would fail.

4. Focus on secrets.

   sentinel scan . --scanners secrets

   Expected: secrets 7 findings, all of them Critical.

5. Write the full report and read it. Save it outside the project, so it is not scanned or committed with it:

   sentinel scan . --scanners secrets --format markdown --output ~/sentinel-lab-report.md

   Open ~/sentinel-lab-report.md in a text editor. Expected: seven findings, most severe first, each with a rule id, file, line, evidence and a recommendation:

   Rule	File	What it found
   S001, S002	.env	An AWS access key id and secret access key
   S018	.env	A database connection string with a password inside
   S003	config/settings.yml	A GitHub token
   S017	config/settings.yml	A private key block
   S013	Dockerfile	An npm access token in an ENV line
   S013	docker-compose.yml	The same npm token, in the service's environment

   Look at the Evidence lines: every secret value shows as [REDACTED]. The report tells you where the secret is without repeating it.

6. Look at one secret yourself. Open .env in a text editor. The AWS key is AKIAIOSFODNN7EXAMPLE, the example value AWS itself publishes in its documentation. In a real project, this is the moment to follow lesson 2: rotate first, then clean up.

Part 2: Fix a finding and add a baseline

7. Fix the token in the Dockerfile. Open Dockerfile and delete this line:

   ENV NPM_TOKEN=npm_EXAMPLEEXAMPLEEXAMPLEEXAMPLEEXAMPLE00

   An ENV line is baked into the image, where anyone who has the image can read it. In a real project you would first revoke the token with npm and create a new one, then pass the new one in only at build time, never in a file.

8. Scan again.

   sentinel scan . --scanners secrets,infra

   Expected: secrets 6 findings (was 7) and infra 17 findings (was 18). One line held two problems: the secret itself, and the infrastructure rule against secrets in ENV. The token in docker-compose.yml is still reported; fixing it is a task for the end of the lab.

9. Create a baseline. Pretend this is an old project with a backlog you cannot fix today:

   sentinel baseline .

   Expected: a line such as Wrote baseline with 54 findings to /home/you/sentinel-lab/.sentinel-baseline.json, and exit code 0.

10. Look inside the baseline.

    head -20 .sentinel-baseline.json

    Expected: the tool name and version, a count of 54, then the start of a list of findings, each with an id, ruleId, file and severity. No code and no secret values: the file is safe to commit.

11. Scan against the baseline.

    sentinel scan . --baseline .sentinel-baseline.json
    echo $?

    Expected: every scanner shows 0 findings, the summary includes New: 0 (Baselined: 54), and the exit code is 0. The old findings are still there; they are set aside so that only new ones count.

Break it: add a new secret

12. Commit a mistake. Add a file with a fake GitHub token, as if someone pasted one into a config:

    echo 'GITHUB_TOKEN=ghp_EXAMPLEEXAMPLEEXAMPLE1111111111111111' > deploy.env
    sentinel scan . --baseline .sentinel-baseline.json
    echo $?

    Expected: secrets 1 finding, Critical: 1, New: 1 (Baselined: 54), and exit code 1. The baseline did not hide it, because it is new. In CI, this pull request would fail.

13. Read the new finding.

    sentinel scan . --baseline .sentinel-baseline.json --format markdown --output ~/sentinel-lab-new.md

    Expected: one finding, CRITICAL S003 — GitHub token committed, at deploy.env:1, with evidence GITHUB_TOKEN=[REDACTED].

14. Fix it the right way. Replace the value with an empty placeholder, as you would in a .env.example file:

    echo 'GITHUB_TOKEN=' > deploy.env
    sentinel scan . --baseline .sentinel-baseline.json
    echo $?

    Expected: New: 0 and exit code 0. A real token would also need revoking, because it could already be in Git history.

Try it: fix the npm token in docker-compose.yml too (delete the environment: line and the NPM_TOKEN: line under it), then run sentinel scan . --baseline .sentinel-baseline.json --write-baseline .sentinel-baseline.json. The rewritten baseline records 52 findings: again one line held two problems, a secret and a secret in a Compose environment. Then fix one source finding: in src/unsafe.js, change findUserByName to the parameterized query from lesson 5 and scan with --scanners source.

Part 3: Check your own machine

These three checks are worth repeating every few months.

15. List your listening ports.

    ss -tln

    Expected: a table like this one, with different ports:

    State  Recv-Q Send-Q Local Address:Port Peer Address:Port
    LISTEN 0      4096       127.0.0.1:631       0.0.0.0:*
    LISTEN 0      4096   127.0.0.53%lo:53        0.0.0.0:*
    LISTEN 0      4096         0.0.0.0:22        0.0.0.0:*
    LISTEN 0      511                *:4173            *:*

    For each line whose address is 0.0.0.0, [::] or *, ask: did I mean to run this, and should my whole network reach it? Run ss -tlnp to see which of your own programs owns a port. Stop anything you do not need, such as a forgotten development server or a Mock Studio project. See Safe networks.

16. Verify a download. Pick an app you were going to install whose releases page publishes a .sha256 file or a SHA256SUMS file. Download both into the same folder, then:

    sha256sum -c <file>.sha256

    or, for a list of many files:

    sha256sum -c --ignore-missing SHA256SUMS

    Expected: the file name followed by OK. Anything else means: do not install it.

17. See a checksum fail. Make a small file of your own and its checksum, then change the file:

    cd ~
    echo "hello" > note.txt
    sha256sum note.txt > note.txt.sha256
    sha256sum -c note.txt.sha256
    echo "changed" >> note.txt
    sha256sum -c note.txt.sha256

    Expected: first note.txt: OK, then note.txt: FAILED and WARNING: 1 computed checksum did NOT match. One added line changed the checksum completely.

18. Review an ApiWorkbench export before sharing it. In ApiWorkbench, select Export, choose ApiWorkbench workspace, leave Include current values off, select Export and save the file into a new, empty folder, ~/export-check. Then search it for anything that looks like a secret:

    grep -n -i -E 'token|password|secret|apikey|api_key|authorization' ~/export-check/*.json
    sentinel scan ~/export-check --scanners secrets,api

    Expected: grep prints every line that names a token, password or key, with its line number; read each one and check whether a real value is there. The scan reports any value that matches its rules, with the value shown as [REDACTED]. A Postman collection export is also checked by the API scanner for secrets stored in the collection.

    If you find a real value, move it from the variable's Initial value to its Current value, set its Type to Secret, and export again. See Export and share.

Use both checks

A scanner can miss a secret. In a test export, DL Sentinel reported a token in JSON Web Token format (at medium severity, which does not fail the default policy, so the exit code was 0) but did not report a plain password stored in a JSON field. grep found both. Read the file, use grep, and use the scanner: each catches what the others miss.

Try it: export again with Include current values on, into the same folder, and run the two commands. Compare: your own tokens are now in the file. Delete that export afterwards.

Clean up

1. Delete the practice copy, the reports and the test files:

   rm -rf ~/sentinel-lab ~/sentinel-lab-report.md ~/sentinel-lab-new.md ~/note.txt ~/note.txt.sha256

2. Delete the export folder, which may contain tokens: rm -rf ~/export-check.

3. Stop any server you started or found running in step 15 that you do not need.

The original sample project in dl-sentinel/tests/fixtures/vulnerable-app is unchanged.

Check yourself

QuizLab: Find the secrets

Question 1 of 6

Why does the lab scan a copy of tests/fixtures/vulnerable-app instead of the original?

Score: 0

What you learned

• A scan's summary gives counts; the Markdown report gives each finding with file, line, redacted evidence and advice.
• Fixing one line can clear more than one finding, and a scan after each fix proves it.
• A baseline sets old findings aside so only new ones fail, which is how a scanner is adopted on an existing project.
• Your own machine needs the same care: open ports, verified downloads, and exports checked before they leave your hands.

Next steps

• Use DL Sentinel in CI: run this scan on every pull request
• Configure scans: suppressions with a reason and an expiry date
• All learning tracks