A.8.29
Tester la sécurité avant toute mise en service
Mesure Technologique
Ce que cela signifie
Définir et conduire des tests de sécurité pendant le développement et à la recette.
Comment StandardOS vérifie cela
Connecté en lecture seule, selon un calendrier. Une vérification réussie garde une entrée de preuve fraîche ; une vérification en échec la laisse expirer, pour qu'une régression remonte au lieu d'attendre l'audit. Chaque intégration, et ce que chaque identifiant peut voir.
- GitHubStandardOS lit si la branche par défaut exige des vérifications de statut réussies avant une fusion, pour que les tests tournent avant qu'une chose soit livrée plutôt qu'après.
- GitHubStandardOS lit si l'analyse de code ou une barrière de revue fait partie de ce qui protège la branche par défaut.
- AWSStandardOS lit si ECR analyse les images avant leur déploiement.
- SnykStandardOS lit quels projets actifs ont désactivé le test des pull requests, de sorte qu'une dépendance vulnérable est signalée après la fusion au lieu d'être arrêtée avant.
Risques que cette mesure traite
Issus du registre de risques de départ que StandardOS propose à la mise en place. Vous conservez, modifiez ou supprimez chacun ; voici ceux qui citent A.8.29 comme traitement.
- Du code écrit par un fournisseur arrive en production sans revueApplication
Ce que les clients demandent sur cette mesure
Les questionnaires de sécurité n'utilisent pas les numéros de mesure. Voici les questions, telles que les clients les posent, qui aboutissent à A.8.29. Chacune est répondue à partir des mêmes quatre enregistrements : le statut dans la DdA, la politique approuvée, une preuve datée et une vérification en direct. La carte complète des trente thèmes.
Suivez-vous un cycle de développement sécurisé avec revue de code et gestion des changements ?
Développement sécurisé, revue de code, gestion des changements, CI/CD · aussi A.8.25, A.8.32
Où cela se situe sous NIS2
A.8.29 fait partie de ce que l'article 21, paragraphe 2, point e), Security in network and information systems acquisition, development and maintenance
, exige. La mettre en œuvre une fois compte pour les deux, et c'est toute la raison d'être de la correspondance NIS2.
Mesures qui vont avec celle-ci
Elles apparaissent ensemble dans le même risque ou la même politique, donc elles sont généralement mises en œuvre ensemble aussi.
- A.8.30Superviser la sécurité quand d'autres développent pour vous
- A.5.19Maîtriser le risque apporté par les fournisseurs
- A.8.25La sécurité tout au long de la fabrication du logiciel
- A.8.26Décider ce qu'une application doit faire en sécurité
- A.8.27Concevoir les systèmes sur des principes sûrs
- A.8.28Écrire du code qui résiste aux attaques
- A.8.31Séparer les environnements de développement, de test et de production
- A.8.33Utiliser des données sûres pour les tests
Ce que coûte la certification ISO 27001. Les jours d'audit sont fixés par l'ISO/IEC 27006, vous pouvez donc calculer votre propre chiffre. Ou voyez quels chapitres StandardOS couvre, y compris ceux qu'il ne couvre pas.
Ce que StandardOS tient prêt pour A.8.29 le jour de l'audit
Une décision d'applicabilité et un brouillon de justification, pré-remplis à partir d'un profil en sept questions et marqués comme brouillon tant que vous ne les avez pas faits vôtres. Un état de mise en œuvre. Des entrées de preuve datées qui expirent, pour que l'export lu par votre auditeur montre ce qui était vrai et quand, classé sous cette référence.