Build out all 27 modules + capstone (#1)
Co-authored-by: claude <claude@jpaul.io> Co-committed-by: claude <claude@jpaul.io>
This commit was merged in pull request #1.
This commit is contained in:
@@ -0,0 +1,42 @@
|
||||
# ci-security.yml — the security gate as a CI step (Module 15).
|
||||
#
|
||||
# This is a PROVIDER-NEUTRAL snippet, not a drop-in file. The YAML below uses the widely-shared
|
||||
# "workflow / job / steps" shape that most hosted and self-hosted CI systems understand (the exact
|
||||
# top-level keys and runner labels follow whatever host you set up in Module 14). Copy the *steps*
|
||||
# into the pipeline you already have rather than adding a second, competing workflow.
|
||||
#
|
||||
# The contract is the same on every platform:
|
||||
# 1. check out the code
|
||||
# 2. install the scanners
|
||||
# 3. run the gate (security-scan.sh), which exits non-zero on any finding -> the job goes red
|
||||
#
|
||||
# Because the real logic lives in security-scan.sh, this file stays tiny and your local run and your
|
||||
# CI run can never drift apart.
|
||||
|
||||
name: security
|
||||
|
||||
on: [push, pull_request] # run on the same events as your Module 14 build/test job
|
||||
|
||||
jobs:
|
||||
security-scan:
|
||||
runs-on: ubuntu-latest # or your self-hosted runner label (Module 19)
|
||||
steps:
|
||||
- name: Check out the code
|
||||
uses: actions/checkout@v4
|
||||
# Secret scanning cares about history. If your tool scans commits (not just the working
|
||||
# tree), fetch full history here — e.g. set `with: { fetch-depth: 0 }`.
|
||||
|
||||
- name: Set up Python
|
||||
uses: actions/setup-python@v5
|
||||
with:
|
||||
python-version: "3.x"
|
||||
|
||||
- name: Install scanners
|
||||
run: pip install pip-audit detect-secrets
|
||||
|
||||
- name: Run the security gate
|
||||
run: |
|
||||
chmod +x security-scan.sh
|
||||
./security-scan.sh
|
||||
# Non-zero exit fails the job. Require this job to pass before merge (branch protection on
|
||||
# your remote, Module 8/10) and the gate actually has teeth.
|
||||
@@ -0,0 +1,28 @@
|
||||
"""Cloud-sync config for tasks-app — a realistic snapshot of what an AI hands you.
|
||||
|
||||
Asked to "sync tasks to a cloud service," a model will cheerfully produce something like this: it
|
||||
works, it reads naturally, it passes lint and tests... and it has a live credential baked straight
|
||||
into the source. That is the *exact* failure mode Module 15's secret-scanning gate exists to catch.
|
||||
|
||||
DO NOT copy this pattern. The point of this file is to be caught by a scanner, not imitated.
|
||||
The fix (read from the environment) is shown at the bottom, commented out, so you can see the
|
||||
difference once Part C of the lab is done.
|
||||
"""
|
||||
|
||||
# --- The problem the scanner should flag -------------------------------------------------------
|
||||
# A hardcoded API key. Looks like a normal string literal; lint and tests will never complain.
|
||||
SYNC_API_KEY = "sk_live_9c3f2a7b41d84e0fa6b2c5d8e1f09a73bdac46"
|
||||
SYNC_ENDPOINT = "https://api.example-task-cloud.com/v1/sync"
|
||||
|
||||
|
||||
def sync_headers() -> dict:
|
||||
return {"Authorization": f"Bearer {SYNC_API_KEY}"}
|
||||
|
||||
|
||||
# --- The fix (Part C) --------------------------------------------------------------------------
|
||||
# Read the secret from the environment instead of committing it. Proper secret management — env
|
||||
# files, secret stores, per-environment config — is Module 17. This is just enough to make the
|
||||
# scanner go quiet honestly.
|
||||
#
|
||||
# import os
|
||||
# SYNC_API_KEY = os.environ["SYNC_API_KEY"] # set it outside the repo; never commit the value
|
||||
@@ -0,0 +1,24 @@
|
||||
# Dependencies an AI "suggested" for the tasks-app cloud-sync feature.
|
||||
#
|
||||
# This file is deliberately booby-trapped with the three things AI gets wrong about dependencies.
|
||||
# Read it before you run anything — every line looks plausible, which is the whole problem.
|
||||
#
|
||||
# Work through it in Part B of the lab:
|
||||
# 1) `pip-audit -r requirements.txt` will FAIL TO RESOLVE because of the bad names below.
|
||||
# 2) Comment out the unresolvable lines (do NOT "autocorrect" them to the nearest real name).
|
||||
# 3) Re-run; the real-but-old package will report an advisory. Bump it until the scan is clean.
|
||||
|
||||
# (1) REAL package, pinned to a KNOWN-VULNERABLE old version.
|
||||
# SCA should flag an advisory here and tell you the fixed version. (Verify-before-publish:
|
||||
# confirm this version still trips your scanner; re-pin if the advisory DB has moved.)
|
||||
requests==2.19.1
|
||||
|
||||
# (2) TYPOSQUAT of a real package ("requests"). One transposed letter. Does not exist on the
|
||||
# public index today — the resolver will reject it. The danger isn't the 404; it's "fixing"
|
||||
# it by guessing instead of verifying what was actually meant.
|
||||
reqeusts==2.31.0
|
||||
|
||||
# (3) HALLUCINATION — a plausible-but-invented name the model produced from thin air. This is the
|
||||
# slopsquatting target: register this name with malware and the next person to `pip install`
|
||||
# gets owned. Confirm it does not resolve; never add it without verifying the real project.
|
||||
task-cloud-sync-client==1.4.2
|
||||
@@ -0,0 +1,48 @@
|
||||
#!/usr/bin/env bash
|
||||
#
|
||||
# security-scan.sh — the security gate for tasks-app (Module 15).
|
||||
#
|
||||
# Runs two scanners and exits non-zero if EITHER finds something. That non-zero exit is what turns
|
||||
# a CI run red (Module 14). One script, two homes: run it by hand for fast local feedback, and call
|
||||
# it from the pipeline so the same definition of "a finding" enforces the merge.
|
||||
#
|
||||
# These two tools (pip-audit, detect-secrets) are concrete examples of their categories — SCA and
|
||||
# secret scanning. Swap in any equivalent; keep the contract the same: scan, print, fail on findings.
|
||||
#
|
||||
# Usage: ./security-scan.sh
|
||||
# Install: pip install pip-audit detect-secrets
|
||||
|
||||
set -u # treat unset vars as errors; we manage exit codes explicitly below.
|
||||
|
||||
status=0
|
||||
|
||||
echo "=== Gate 1: SCA / dependency scan (pip-audit) ==="
|
||||
if [ -f requirements.txt ]; then
|
||||
if ! pip-audit -r requirements.txt; then
|
||||
echo ">> SCA gate FAILED: unresolvable or vulnerable dependency. See above." >&2
|
||||
status=1
|
||||
fi
|
||||
else
|
||||
echo "(no requirements.txt found — skipping SCA)"
|
||||
fi
|
||||
|
||||
echo
|
||||
echo "=== Gate 2: secret scan (detect-secrets) ==="
|
||||
# detect-secrets prints a JSON report of any secrets it finds. We treat a non-empty results set as a
|
||||
# failure. `python -c` keeps this portable (no jq dependency).
|
||||
report="$(detect-secrets scan)"
|
||||
if printf '%s' "$report" | python -c 'import sys, json; sys.exit(0 if json.load(sys.stdin).get("results") else 1)'; then
|
||||
echo "$report"
|
||||
echo ">> SECRET gate FAILED: a credential was detected in the tree. See report above." >&2
|
||||
status=1
|
||||
else
|
||||
echo "no secrets detected."
|
||||
fi
|
||||
|
||||
echo
|
||||
if [ "$status" -ne 0 ]; then
|
||||
echo "SECURITY GATE: FAILED" >&2
|
||||
else
|
||||
echo "SECURITY GATE: passed"
|
||||
fi
|
||||
exit "$status"
|
||||
Reference in New Issue
Block a user