Une entreprise logicielle indépendante de Vancouver.
Nous concevons des outils pour les points du cycle de vie logiciel où une défaillance silencieuse devient un incident, et nous les exploitons nous-mêmes avant de les proposer à qui que ce soit.
La livraison a devancé les pratiques censées la sécuriser.
Les équipes qui adoptent des assistants d'IA livrent plus de changements, et les livrent plus vite. Une part croissante de ces changements est écrite par quelque chose qui ne porte pas le contexte qu'un relecteur possède, et elle arrive dans le même pipeline, le même registre et les mêmes systèmes de production que tout le reste.
Les pratiques qui tiennent sous cette pression ne sont pas nouvelles. Des changements revus, un pipeline qui bloque au lieu d'avertir, le contrôle de ce qui entre dans un build et la surveillance de ce qui tourne étaient l'objectif bien avant l'IA. La plupart des équipes n'ont jamais fini de les adopter, parce que chacune est un projet à part entière.
C'est ce que nous construisons, et c'est notre façon de travailler. Nous nous autoévaluons aussi par rapport à notre cadre de maturité AI DevSecOps à six domaines, et le Centre de confiance indique comment en demander les résultats.
Lire le Centre de confiance →Comment un changement atteint la production.
Ce site est livré sous les mêmes règles que tout ce que nous exploitons.
Des changements revus sur une branche protégée.
Chaque changement apporté à ce site passe par une merge request revue sur une branche main protégée. Un changement n'est fusionné qu'après revue et un pipeline qui passe.
Un pipeline qui bloque au lieu d'avertir.
Chaque changement déclenche le linting, le formatage, la vérification de types, la parité des locales, un shellcheck du script de déploiement et un build de production complet. Une fusion n'aboutit que si tout passe.
Nos builds s'approvisionnent par notre propre registre.
Chaque paquet que ce site installe en CI passe par le registre privé que nous exploitons, et les fournisseurs Terraform passent par le même miroir. Si ce registre est injoignable, le build échoue au lieu de se rabattre sur le registre public.
La mise en production est une étape délibérée.
Un pipeline au vert ne publie rien. La mise en production du site construit est une étape manuelle, déclenchée par une personne une fois le pipeline passé.
Notre page d'état publique à status.dependably.ca fonctionne avec notre propre outil de surveillance, et nos autres dépôts ajoutent une vérification de la chaîne d'approvisionnement du lockfile, une vérification d'alignement sur les spécifications et une analyse de secrets.
Où cela rejoint des cadres que les évaluateurs connaissent.
Nos outils sont conçus en accord avec les recommandations OWASP pour la sécurité applicative et les principes SLSA relatifs à la chaîne d'approvisionnement, et nous évaluons notre propre pipeline de build par rapport à NIST SSDF (SP 800-218).
Où vérifier tout ceci.
Le code source, la licence et le processus de divulgation sont publics.
Ce que nous hébergeons exécute le code que nous publions.
L'édition hébergée repose sur le même moteur que l'Édition Communauté auto-hébergée, avec les mêmes politiques et le même flux d'audit. Le code source publié sur GitHub est ce moteur.
L'Édition Communauté est open source.
L'Édition Communauté est sous licence Apache-2.0 et développée au grand jour sur GitHub. Le code source complet est lisible et exécutable sans compte.
La politique de sécurité est publique.
Comment signaler une vulnérabilité, et ce qui se passe après un signalement, sont documentés dans notre politique de sécurité publique à dependably.ca/security.