layerleak

Layerleak est un scanner de secrets pour images OCI en lecture seule. Il résout les références d'images publiques sans démon Docker, vérifie le contenu téléchargé par rapport aux digests OCI, reconstruit l'état des couches, inspecte les artefacts supprimés et les métadonnées d'image, et renvoie des résultats expurgés et riches en provenance.

Il prend en charge Docker Hub, GHCR, Quay, GCR, MCR, Amazon ECR Public et d'autres registres compatibles OCI. Les résultats peuvent être enregistrés au format JSON et persistés dans PostgreSQL pour l'API fournie.

• Documentation
• Spécification OpenAPI
• Journal des modifications
• Politique de sécurité
• Contribution

Cette arborescence de développement documente la branche 3.0.0 sur le chemin de module github.com/brumbelow/layerleak/v3. La commande de version candidate présentée ci-dessous ne devient installable qu'après la publication de ce tag exact. Les étiquettes 3.0.0 dans le journal des modifications et le document OpenAPI sont intentionnellement figées afin qu'une version candidate acceptée puisse être promue depuis le même commit source.

Modèle de sécurité

Layerleak analyse du contenu d'image non fiable, ses valeurs par défaut sont donc intentionnellement limitées et échouent en mode fermé :

• les limites d'images, de manifestes, de configurations, de réponses de tags, de fichiers, de couches, d'état conservé et de résultats empêchent tout travail non borné ;
• les corps des manifestes, configurations et couches sont vérifiés par rapport à leurs digests OCI annoncés avant utilisation ;
• les redirections sont plafonnées et revalidées ;
• les destinations de registre et d'authentification privées, loopback, link-local et autrement non publiques sont bloquées, sauf si leur hôte exact est explicitement autorisé ;
• les résultats, les réponses de l'API, l'historique des analyses et les journaux sont expurgés par défaut ;
• une couverture incomplète est signalée comme partial ou failed, jamais comme une analyse propre.

Layerleak ne vérifie pas si un identifiant détecté est actif. L'API n'a pas de modèle d'autorisation : elle est ouverte par défaut, et la vérification par jeton partagé LAYERLEAK_API_BEARER_TOKENS, activée en option, constitue une défense en profondeur pour les chemins /api/, et non un contrôle d'accès. Dans tous les cas, ne l'exposez que sur un réseau de confiance ou derrière une passerelle authentifiée.

Installer le CLI

Layerleak nécessite Go 1.27.1 ou une version ultérieure.```bash go install github.com/brumbelow/layerleak/v3@latest layerleak --version layerleak --help

Le chemin de module `/v3` est la cible d'installation canonique ; le binaire installé est
toujours nommé `layerleak`. Épinglez explicitement une version stable ou une release candidate lorsque
la reproductibilité est importante :```bash
go install github.com/brumbelow/layerleak/[email protected]
go install github.com/brumbelow/layerleak/[email protected]

@latest sur le chemin /v3 sélectionne la version v3 publiée la plus élevée. Go exclut les préversions de @latest dès qu'une version stable existe, donc tant que seules des release candidates sont publiées, @latest se résout vers la candidate la plus récente. Le chemin racine github.com/brumbelow/layerleak sans /v3 reste à v1.0.0 pour toujours ; incluez toujours /v3. Les builds par checkout rapportent une version de développement dérivée du VCS, incluant un marqueur de worktree modifié, ou dev sans informations VCS. Les binaires installés via une release rapportent la version de module résolue via layerleak --version.

Télécharger une archive de release

Chaque release attache également des archives CLI précompilées, donc aucune toolchain Go n'est nécessaire : layerleak_<version>_<os>_<arch>.tar.gz pour linux et darwin sur amd64 et arm64 (contenant layerleak, LICENSE et THIRD_PARTY_NOTICES.md) et layerleak_<version>_windows_amd64.zip (layerleak.exe). Chaque release porte un layerleak_<version>_checksums.txt signé sans clé par le workflow de release (layerleak_<version>_checksums.txt.sigstore.json) et une attestation de provenance de build pour chaque archive. Vérifiez avant d'exécuter :```bash version=v3.0.0 archive="layerleak_${version}linux_amd64.tar.gz" checksums="layerleak${version}_checksums.txt" base="https://github.com/brumbelow/layerleak/releases/download/${version}" curl --fail --location --proto '=https' --tlsv1.2 --remote-name-all
"${base}/${archive}" "${base}/${checksums}" "${base}/${checksums}.sigstore.json"

sha256sum --check --ignore-missing "${checksums}" cosign verify-blob
--bundle "${checksums}.sigstore.json"
--certificate-identity 'https://github.com/Brumbelow/layerleak/.github/workflows/container-release.yml@refs/heads/main'
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com'
"${checksums}" gh attestation verify "${archive}" --repo Brumbelow/layerleak
--signer-workflow Brumbelow/layerleak/.github/workflows/container-release.yml
--source-ref refs/heads/main --deny-self-hosted-runners

tar -xzf "${archive}" layerleak ./layerleak version

La signature prouve que le fichier de sommes de contrôle provient du workflow de publication de ce dépôt sur `main`, la somme de contrôle lie l'archive à ce fichier, et l'attestation lie indépendamment l'archive à l'exécution du workflow qui l'a construite. `release-manifest.json` sur la publication liste chaque archive et le digest du binaire qu'elle contient. Une publication stable reconstruit le commit de la release candidate acceptée avec la chaîne de version stable et refuse de publier à moins que la reconstruction ne reproduise les binaires de la candidate octet par octet, de sorte que `layerleak version` rapporte exactement le tag que vous avez téléchargé.

### GitHub Action