Lab — Scan & Hardening: docker-bitcoin-books#
Perché questo lab#
Lab separato, non collegato al docker-dmz.md (quello resta network segmentation + WAF). Qui il target è un repo Docker reale e tuo: docker-bitcoin-books, parte del libro Bitcoin dalla teoria alla pratica.
Stessa logica di Burrito/Chatwoot nel percorso DevSecOps: infrastruttura reale invece di lab sintetici — "ho messo in sicurezza il repo del mio libro" batte "ho scansionato un progetto demo". In più questo repo tocca uno stack diverso da Burrito (Debian/Python/Bash invece di Node/TS), quindi copre superficie diversa nel portfolio.
Correlazione carriera: CARRIERA-DEVSECOPS.md elenca tra i progetti non negoziabili il "Crypto/Fintech Security Toolkit (differenziatore)" — audit su integrazioni exchange/wallet, "in Italia lo fanno in pochissimi". Questo lab è il seme concreto di quel progetto: non più un'idea vaga, un repo Bitcoin reale da mettere in sicurezza.
Cosa c'è nel repo (verificato)#
| Elemento | Dettaglio |
|---|---|
Dockerfile | FROM debian:12-slim, installa build tools + curl/wget/git + openssl/gnupg + python3-pip/python3-base58 |
| Bitcoin Core | Versione pinnata via ARG VERSION=26.0 + verifica firma GPG (BITCOIN_CORE_SIGNATURE) |
| USER | Non specificato → gira come root |
docker-compose.yml | 2 servizi: bitcoin-in-action (porte 18443/18444, 3 volumi) + explorer (btc-rpc-explorer, porta 3002, dipende dal nodo) |
| Rete | bridge custom mynetwork |
| Auth explorer→nodo | cookie-based (non password hardcoded — buono di default, da verificare) |
DockerfileExplorer | immagine separata per btc-rpc-explorer |
Backlog (obiettivi, non comandi — provo prima io)#
1. Baseline: scan dell'immagine#
Obiettivo: sapere cosa c'è di vulnerabile PRIMA di toccare niente. Trivy scansiona sia i pacchetti OS Debian sia le dipendenze Python. Trova tu il comando (stesso tool già nel syllabus, argomento 9/container security).
2. SCA sulle dipendenze Python#
python3-base58 e le altre dipendenze pip: installate con versioni pinnate o latest implicito? Verifica se ci sono CVE note.
3. Secrets scan#
TruffleHog su tutto il repo (non solo Dockerfile): bitcoin.conf, entrypoint.sh, docker-compose.yml. L'auth via cookie è il pattern giusto — verifica che non ci sia comunque un rpcuser/rpcpassword hardcoded dimenticato da qualche parte (capita spesso nei tutorial Bitcoin più vecchi).
4. Hardening Dockerfile#
- Nessun
USER→ root. Aggiungi un utente non privilegiato e verifica che il nodo Bitcoin regtest funzioni comunque (bitcoind non ha bisogno di root). - Verifica che
entrypoint.shcontrolli davvero la firma GPG prima di eseguire il binario scaricato (supply chain security, non solo scaricarla e ignorarla). - Pacchetti installati:
build-essential,autoconf,libtoolservono solo per compilare — se il binario è precompilato/verificato, questi pacchetti aumentano la superficie d'attacco dell'immagine finale senza motivo. Multi-stage build?
5. DAST sull'explorer (opzionale, stretch goal)#
explorer è una vera web app esposta su :3002. ZAP baseline scan, stesso tool del syllabus argomento 6.
6. Output finale#
- Findings documentati (prima/dopo)
- Dockerfile hardened committato
- Se il lab regge: candidalo formalmente come base del "Crypto/Fintech Security Toolkit" in
CARRIERA-DEVSECOPS.md— a quel punto si arricchisce con audit specifici su flussi Bitcoin, non solo hardening container
Note#
- Repo del libro: non rompere l'esperienza didattica per chi lo usa a scopo di studio (regtest, non mainnet — nessun fondo reale in gioco, quindi il rischio hardening è basso)
- Se emergono pattern riusabili (es. script Trivy+TruffleHog generico), sono candidati per essere riapplicati anche a Burrito
