Solutions

Gardez les mauvais paquets hors de vos builds.

Un registre public sert tout ce qu'un build lui demande. Une version compromise, un paquet qui usurpe un nom interne ou une version avec une faille connue s'installe sur votre exécuteur CI sous vos identifiants, et le build reste au vert.

Pourquoi cela se répète

Rien entre le registre et le build ne dit non.

Un outil de build résout un nom en une version et l'installe. Le registre public répond à chaque demande de la même façon, que la version ait été publiée par le mainteneur ou par la personne qui lui a volé son jeton de publication. Les scripts d'installation s'exécutent avec les droits de l'exécuteur, et l'exécuteur détient vos identifiants de déploiement.

Un fichier de verrouillage fige un choix fait une fois. Il ne le revérifie pas. Un avis publié des mois après la mise en cache de la version ne change rien au fichier de verrouillage, donc le build continue de passer avec une vulnérabilité connue à l'intérieur.

Les noms de paquets internes sont le cas silencieux. Si un nom privé n'est pas réservé, un paquet public du même nom peut gagner la résolution et atterrir dans le build sans la moindre erreur.

Comment nous le résolvons

Chaque installation passe par un registre que vous exploitez, avec la politique devant le cache.

Dependably Packages s'exécute à l'intérieur de votre périmètre, entre vos builds et les registres publics. Il relaie et met en cache npm, PyPI, Maven, NuGet, Cargo, Go, RPM, Alpine apk, OCI, Terraform et Hex par un seul endpoint, et rien n'est servi avant d'avoir été vérifié, confronté à votre politique et analysé.

Récupération vérifiée

Sur un défaut de cache, et seulement pour un nom que les listes d'autorisation et de blocage de votre organisation permettent, l'artefact amont est récupéré et vérifié par somme de contrôle face à l'empreinte publiée en amont, là où il en publie une. Une discordance est un échec audité et un 502, jamais un fichier en cache. Les signatures d'éditeur peuvent être vérifiées face aux ancres de confiance que vous épinglez, pour npm, PyPI, NuGet, Maven, RPM, Alpine et Terraform.

somme de contrôle · signature

Porte de politique

La version mise en attente est confrontée à votre politique avant qu'une ligne de catalogue n'existe : licence, sévérité OSV, inscription au KEV de la CISA, probabilité EPSS, scripts d'installation, et un âge de publication minimal qui retient une publication fraîche jusqu'à ce qu'elle ait été publique assez longtemps pour qu'une compromission remonte. Une version refusée l'est pour chaque build.

décision de politique

Noms réservés

Vos espaces de noms internes peuvent être réservés sur le registre, de sorte qu'un paquet public du même nom ne peut pas être résolu par un build. Les listes d'autorisation et de blocage par motif de paquet couvrent le reste.

espace de noms

Réanalyse quotidienne

Chaque version en cache est analysée par rapport à la base OSV toutes les 24 heures par défaut. Un avis publié après l'arrivée d'une version remonte quand même, et votre politique de sévérité s'applique au résultat.

OSV · quotidien
Ce que vous obtenez

Un build qui ne peut installer que ce que vous avez autorisé.

Chaque récupération, chaque décision de politique et chaque événement de jeton est écrit dans un journal d'audit en ajout seul, de sorte que savoir si une version a déjà atteint un build est une requête plutôt qu'une fouille des journaux d'exécuteur.

  • Une version refusée fait échouer l'installation avec la raison, au registre, avant qu'un seul code ne s'exécute.
  • La même décision s'applique à chaque pipeline et à chaque poste de développement pointé sur l'endpoint.
  • Le journal d'audit est transmis à votre SIEM en NDJSON par webhook, ou en CEF ou RFC5424 par syslog.
  • Les déploiements isolés analysent ce que vous publiez par rapport à une base OSV chargée hors ligne, sans réseau sortant après l'installation.
Entrée du journal d'audit
  • refusé npm/example-widget@2.4.1
  • raison âge sous le minimum
  • jeton ci-main
  • transmis siem-webhook · en file
Où cela s'exécute

Auto-hébergé, ou hébergé par nous sur demande.

Dependably Packages est livré sous forme d'une seule image de conteneur sous Apache-2.0, avec SQLite par défaut et PostgreSQL quand vous avez besoin de haute disponibilité, le SSO SAML ou des comptes locaux dès le premier jour, et aucun appel vers nos serveurs. Dependably Cloud fait tourner le même moteur, les mêmes politiques et le même flux d'audit sur un forfait payant que nous exploitons; joignez-nous pour discuter d'un déploiement hébergé.