Service qui compile les dépôts open-source enregistrés dans des VM hors ligne isolées et les analyse à la recherche de vulnérabilités de sécurité, en envoyant par e-mail les résultats avec des reproducteurs et des correctifs proposés.
OSS Scanner est un service d'Anthropic permettant d'analyser les dépôts open source critiques à la recherche de vulnérabilités de sécurité. Pour en savoir plus sur ce service, consultez red.anthropic.com/oss-scanner.
Notez que l'utilisation de cet outil est soumise aux termes et conditions décrits dans les conditions d'OSS Scanner.
Inscrivez un projet open source en ouvrant une pull request qui ajoute un répertoire :
projects/<name>
Notre scanner de sécurité construit votre projet dans une VM isolée, puis l'analyse sans accès à Internet et envoie par e-mail ce qu'il trouve à primary_contact (et à toute adresse en CC), chaque rapport contenant un reproducer et un patch proposé lorsqu'il est disponible. Les rapports sont générés par un modèle et ne sont pas relus par un humain. Pour cette raison, nous n'appliquons pas de période de divulgation de 90 jours à ces résultats et ne les rendrons pas publics. Les propriétaires de projet doivent fournir un project.yaml (pour configurer le scanner), un Dockerfile (indiquant comment construire le projet), et éventuellement un threat_model.md (fournissant une modélisation des menaces propre au projet).
Partez de templates/project.yaml :
repo: https://github.com/example/project # required: the git repository to scan; add #branch to pin one
primary_contact: [email protected] # required: reports and build problems go here (one address)
auto_ccs: # optional: more addresses on every mail
- [email protected]
homepage: https://example.org # optional
disabled: false # optional: true pauses reports without removing the enrolment
dockerfile: .oss-scanner/Dockerfile # required unless a Dockerfile sits in this repo next to your project.yaml
threat_model: .oss-scanner/threat_model.md # optional; also supports placing the file in this repository
repo et primary_contact sont toujours requis. dockerfile est requis, sauf si vous conservez votre Dockerfile à côté de project.yaml (voir ci-dessous). Les autres champs sont facultatifs.
Les adresses e-mail dans project.yaml sont publiques. Utilisez des adresses que vous acceptez de voir publiées, comme un alias de sécurité.
Pour recevoir les rapports chiffrés, ajoutez votre clé publique OpenPGP au format armored. Les rapports sont alors envoyés uniquement à primary_contact ; pgp ne peut pas être combiné avec auto_ccs :
pgp: |
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBF...
-----END PGP PUBLIC KEY BLOCK-----
Vous devez fournir un Dockerfile, à exactement l'un de ces deux emplacements :
dockerfile: avec son chemin (nous suggérons un emplacement comme .oss-scanner/Dockerfile). C'est l'option préférée car elle vous permet de mettre à jour la construction sans pull request ici ; ou,project.yaml, sous la forme projects/<name>/Dockerfile, sans clé Dockerfile: définie dans le project.yaml. Si vous préférez ne pas ajouter de fichiers à votre dépôt, placez-le ici et le scanner le construira exactement comme il le ferait avec une copie interne au dépôt.(Le threat model fonctionne de la même manière. Définissez le champ threat_model pour son emplacement dans votre dépôt, ou placez-le ici à projects/<name>/threat_model.md.)
Le but du Dockerfile est de configurer votre environnement, d'installer toutes les dépendances et de construire le projet. La configuration initiale du projet s'exécute avec l'accès réseau activé, mais l'audit de sécurité qui suit s'exécute sans accès à Internet. Tout ce dont la construction ou les tests ont besoin doit être récupéré lors de la configuration initiale du Dockerfile. Nous vous recommandons de vérifier que vos tests passent à l'intérieur de l'image construite.
Le fichier threat_model.md (facultatif mais fortement recommandé) vous permet de fournir au scanner une documentation sur vos objectifs de sécurité. Nous avons constaté qu'il est particulièrement utile de fournir des indications sur la façon dont vous évaluez la gravité des rapports (par exemple, considérez-vous une SQLi post-authentification comme élevée ou critique ? les débordements de tampon sans exploit démontré sont-ils plafonnés à élevée ? quand un XSS stocké est-il moyen, élevé ou critique ?). Ce fichier peut également préciser ce que fait le projet, où entrent les entrées non fiables, quels composants comptent et lesquels sont hors périmètre, à quoi vous souhaitez que les rapports et les patchs ressemblent, ou tout autre élément que vous jugez important ou utile.
Nous vous suggérons d'exécuter deux commandes avant d'ouvrir une pull request :
tools/validate.py vérifie projects/<name>/ par rapport aux règles ci-dessus.tools/check <name> construit votre projet comme le fera notre scanner, et ouvre un shell dans l'image finale sans réseau. Si vos tests passent dans ce conteneur, notre scanner fonctionnera probablement avec votre projet. tools/check --qemu <name> fait la même chose à l'intérieur de machines virtuelles configurées comme celles du scanner.Ces outils nécessitent que votre hôte ait installé git, Docker et Python 3 avec PyYAML (pip install pyyaml) ; --qemu nécessite Linux sur x86-64 avec QEMU au lieu de Docker.
primary_contact avec un message d'erreur.primary_contact et à toute adresse en CC supplémentaire, avec les étapes de reproduction et un patch proposé lorsqu'il est disponible.Vous pouvez modifier votre projet à tout moment via une PR. Pour désinscrire votre projet, définissez le champ disabled sur true pour suspendre les rapports, ou supprimez projects/\<name\>/ pour retirer complètement le projet.
tools/check exécute le Dockerfile de votre projet avec accès au réseau, comme le ferait docker build. Avec --qemu, la construction s'exécute à l'intérieur d'une machine virtuelle, ce qui la protège de vos fichiers, mais elle peut toujours atteindre les services sur votre ordinateur et votre réseau local. Ne vérifiez que des projets en lesquels vous avez confiance, ou utilisez une machine sans rien à perdre.tools/check installe Claude Code dans l'image qu'il construit (comme le fait le scanner). Claude Code est couvert par ses propres conditions.Veuillez consulter red.anthropic.com/oss-scanner.
Statut de maintenance : ce dépôt est activement maintenu par Anthropic. Nous examinons et fusionnons uniquement les pull requests d'inscription (modifications sous projects/<name>/) ; nous n'acceptons pas d'autres contributions, y compris les modifications de tools/ ou templates/. Consultez CONTRIBUTING.md pour savoir comment s'inscrire, SECURITY.md pour signaler une vulnérabilité dans ce dépôt, et CODE_OF_CONDUCT.md.