👋 🏨 🏴󠁧󠁢󠁷󠁬󠁳󠁿 (S) SDLC, ou Comment rendre le développement plus sûr. Partie 1 👩🏾‍🤝‍👩🏼 💷 👨🏼‍⚖️

Chaque année, la culture du développement se développe, de nouveaux outils pour garantir la qualité du code et de nouvelles idées sur la façon d'utiliser ces outils apparaissent. Nous avons déjà écrit sur le dispositif d'analyse statique , sur les aspects des analyseurs auxquels vous devez prêter attention et, enfin, sur la façon dont, d'un point de vue organisationnel, vous pouvez créer un processus basé sur l'analyse statique .

Sur la base des problèmes que nous rencontrons souvent, nous avons décrit l'ensemble du processus d'introduction d'un scanner de code dans un processus de développement sécurisé. Aujourd'hui, nous allons parler de la façon de choisir l'analyseur qui vous convient.

D'une manière ou d'une autre, tous les développeurs sont confrontés à une analyse statique (analyse de code sans exécution). Par exemple, lorsque le compilateur génère des erreurs ou des avertissements basés sur les résultats de l'assembly, ce sont les résultats d'une analyse statique. Nous utilisons souvent des linters - il s'agit également d'une analyse statique, bien que souvent très simple. Il existe des exemples plus intéressants - spotbugs (anciennement findbugs), qui vous permet de trouver des vulnérabilités assez intéressantes dans le bytecode Java, ou le célèbre SonarQube - une plate-forme pour surveiller la qualité du code.

Cependant, les outils SAST à part entière sont encore rarement rencontrés. Tout d'abord, nous parlons d'outils qui peuvent trouver des vulnérabilités complexes. Comme il s'avère en pratique, les outils ouverts bien connus ne peuvent pas faire face à cette tâche, du moins parce qu'ils se concentrent sur un autre domaine (bogues et vulnérabilités simples). Un bon outil SAST implémente une analyse interprocédurale des flux de données. L'analyse ne doit pas avoir lieu sur le texte du programme, mais sur la présentation interne - CFG, AST, etc. En savoir plus à ce sujet dans l'article précédent .

SAST

Voici un exemple - l'injection SQL bien connue. Dans cet exemple, les données de l'utilisateur tombent dans la fonction terminée de la requête, transmises à la fonction injectableQuery, et déjà là, elles tombent dans la requête SQL, ce qui rend l'application vulnérable à l'injection SQL.

Pour trouver une telle vulnérabilité, il faut comprendre d'où peuvent provenir les «mauvaises» données, comment ces données peuvent être validées, où elles ne peuvent pas être utilisées. Et le plus important - vous devez surveiller le transfert de données dans toute l'application, c'est l'analyse du flux de données. L'exemple est très simple, dans une application réelle, les données peuvent passer par de nombreuses fonctions et modules, affectations et synonymes.

Il est clair que la recherche de texte ne trouvera pas une telle vulnérabilité. L'analyse intraprocédurale ne trouvera pas non plus, et dans certains outils ouverts seulement elle est implémentée. Pour trouver de telles vulnérabilités (et il s'agit généralement des vulnérabilités les plus critiques, c'est-à-dire l'objectif principal de l'outil SAST), nous avons besoin d'algorithmes bien développés pour l'analyse inter-procédures du flux de données avec de grandes bases de règles.

C'est sur la base de la complexité algorithmique que se posent un certain nombre de problèmes techniques qui distinguent l'implémentation de l'outil SAST des autres analyseurs statiques, par exemple SonarQube. Nous discuterons de ces questions dans une série d'articles. Spoiler: consommation de ressources, durée d'analyse, faux positifs.

Il convient de noter qu'en plus des algorithmes, un bon outil encapsule tous les calculs dans un shell d'interface pratique, vous permettant d'utiliser SAST sans préparation sérieuse. Ces outils sont également intégrés dans le CI / CD à l'aide de plugins et d'API, automatisant ainsi la recherche de vulnérabilités et vous permettant de créer des processus de développement sécurisés.

Dans le premier article, nous avons essayé de classer les principaux problèmes qui se posent lors de l'étude de SAST, ainsi qu'après la décision de mettre en œuvre l'outil. Nous allons parler de certains problèmes ici, certains iront aux articles suivants.

Commençons

Pourquoi SAST si vous avez déjà des analyseurs statiques gratuits?

Nous avons partiellement abordé cette question dans la partie précédente. Bien sûr, nous ne diminuons en rien les mérites des outils ouverts. Tout le monde sait que SonarQube est un excellent outil pour automatiser l'évaluation de la qualité du code, avec un grand nombre de langues, d'intégrations et de plugins pris en charge. SonarQube est bon pour être intégré dans le processus de développement, mais est plutôt destiné à compter diverses mesures de code et à rechercher des erreurs ou des vulnérabilités assez simples. Il n'implémente pas d'analyse interprocédurale du flux de données; par conséquent, il ne peut pas être utilisé pour rechercher des vulnérabilités complexes. Habituellement, nous recommandons d'utiliser à la fois SonarQube et un bon outil SAST (il peut être utile ici si l'outil SAST peut s'intégrer à SonarQube).

Il existe d'autres bons analyseurs statiques ouverts. Vous pouvez appeler des spotbugs (findbugs) pour le bytecode JVM avec le plugin find-sec-bugs, qui implémente l'analyse en cours du flux de données avec un petit ensemble de règles. Il existe un analyseur de bandits bien connu pour Python. On ne peut que mentionner l'analyseur statique intégré à clang, qui a un bon moteur d'analyse et une bonne base de règles.

Les problèmes de ces outils sont qu'ils sont généralement assez étroitement spécialisés (par exemple, adaptés à une langue), implémentent des algorithmes simples (c'est-à-dire qu'ils ne permettent pas de trouver des vulnérabilités complexes) et ont des bases de règles beaucoup plus petites que les outils commerciaux. De plus, ils ont un ensemble plus petit de fonctionnalités, à la fois d'interface et d'intégration. Eh bien, nous pouvons mentionner le manque de soutien.

D'un autre côté, de bons outils SAST commerciaux (et il y en a aussi de mauvais) implémentent des algorithmes spécifiques complexes et ont des bases de règles étendues qui peuvent inclure des milliers d'enregistrements. Habituellement, ils prennent en charge de nombreux langages de programmation, ont une interface riche et des capacités d'intégration (plugins, API). Ci-dessous, je donne un exemple du type d'intégration dont nous parlons.

Et encore plus bas, regardez un exemple de schéma d'intégration qui peut être construit sur la base d'un outil SAST. En général, le schéma ne diffère pas de l'introduction d'autres moyens de contrôle de la qualité du code. Les développeurs écrivent du code et peuvent immédiatement exécuter une vérification SAST. Le code pénètre dans le référentiel et à partir de là, sur différents déclencheurs utilisant CI / CD, pénètre dans SAST. Les résultats de l'analyse peuvent être visualisés dans l'interface SAST, ou ils peuvent se retrouver dans des outils qui prennent en charge le processus de développement (bug tracker, mail, etc.).

Quel outil SAST choisir?

Je vais m'attarder un peu sur le choix d'un outil. Il existe de nombreux outils SAST, généralement plusieurs pièces sont présentées sur le marché (3-4). La question se pose, comment choisir le bon outil, que rechercher? Ici, je ne vais pas surprendre, je vais me concentrer sur trois points: la comparaison fonctionnelle, la comparaison de la qualité et les licences. Il est important de prendre l'outil de test (pilote) dans votre circuit local et de vérifier votre code dans votre infrastructure.

Ce serait bien d'essayer toutes les fonctionnalités de l'interface, de comprendre comment elles s'appliquent à votre cas et à quel point elles sont pratiques à utiliser. Je me réfère à l' un des articles précédents . Voici quelques fonctionnalités utiles:

le lancement le plus automatisé de la numérisation (idéalement, sans paramètres inutiles dans deux boutons, vous pouvez exécuter une numérisation);
— , , ;
;
;
;
(, );
;
, “”;
“ , ”;
;
.

Les capacités d'intégration sont très importantes - avec CI / CD, bugtrackers, référentiels, Active Directory. Ce serait bien d'essayer d'automatiser une action simple en utilisant l'API, le cas échéant.

Pour vérifier la qualité dont vous avez besoin pour scanner votre code. Il est bon de choisir plusieurs exemples différents dans différentes langues afin que l'échantillon soit représentatif. Du point de vue de la qualité, vous devez examiner les faux positifs (où il n'y a clairement aucune vulnérabilité, mais l'outil le montre) et les omissions (idéalement, vous devez savoir où sont les vulnérabilités, eh bien, ou comparer les vulnérabilités trouvées dans différents outils). Je porterais un peu moins d'attention aux faux positifs, car il suffit généralement de parcourir les résultats de l'analyse une fois, de marquer les faux, puis ils ne vous dérangeront pas.

Je me concentrerai sur deux points importants. Tout d'abord, il est très important de regarder tout cela en application à votre situation. Vérifiez exactement votre code (SAST peut fonctionner différemment sur différents types d'applications). Recherchez les fonctionnalités dont vous avez besoin pour intégrer l'outil dans le processus de développement. Vérifiez l'intégration avec les systèmes dont vous disposez.

Deuxièmement, il est très important pendant le pilote de communiquer avec le vendeur. SAST n'est pas la chose la plus simple, et il suffit souvent d'obtenir les conseils habituels du vendeur pour apprécier pleinement la puissance de l'outil.

À quel moment commencez-vous la numérisation?

Plus tôt une vulnérabilité est découverte, moins elle est chère. Il y a des horaires farfelus qui errent de présentation en présentation, je ne les ajouterai même pas ici. Mais la déclaration est assez évidente. C'est une chose de corriger la vulnérabilité le lendemain de sa création, une autre chose est d'apporter une modification au serveur de combat lorsqu'il a déjà été piraté. En conséquence, il est nécessaire de transférer l'utilisation de SAST aux premiers stades de développement. Ici, on peut affirmer que l'introduction de SAST dans le développement est en soi un événement coûteux et qu'elle peut ne pas porter ses fruits. Ici, je vais argumenter: la recherche de plusieurs vulnérabilités critiques couvre généralement l'ensemble de l'implémentation (vous pouvez même effectuer une évaluation dans le pilote).

Avec cette approche, nous obtenons également un bonus: lorsque les développeurs voient les résultats SAST «tous les jours», ils avancent dans la connaissance de la programmation sûre, ainsi, en général, la culture du développement sécurisé est améliorée et le code s'améliore.

Bien sûr, lors de l'implémentation de SAST dans le processus de développement, il est nécessaire d'implémenter dans CI / CD, la construction de DevSecOps. La tendance à transférer SAST des contrôles de contrôle avant la publication vers le processus de développement est visible depuis longtemps et au cours des 2-3 dernières années, elle a rattrapé notre marché. Désormais, aucun pilote ne passe sans tester les capacités d'intégration.

Dans le même temps, je laisserais les contrôles de contrôle avant la sortie, idéalement, pour les assemblages binaires (c'est également possible). Vous pouvez ainsi vous assurer qu'aucune nouvelle vulnérabilité n'a été ajoutée lors de l'assemblage et du transfert de l'application vers le produit.

Problèmes techniques

Et puis je vais poser 4 questions tout de suite.

Connectez SAST en SonarQube, quelle est la difficulté?
SAST fonctionne depuis longtemps, comment configurer DevSecOps?
SAST donne des faux positifs, comment configurer Quality Gate?
Et sans faux positifs dans le rapport, plusieurs milliers de vulnérabilités, qu'en faire?

Ce sont les principaux problèmes techniques qui se posent lors de la mise en œuvre de SAST. Ils surviennent pour les raisons suivantes.

En raison de la nature exponentielle des algorithmes, SAST peut fonctionner pendant une longue période et consommer beaucoup de ressources - bien plus qu'un linter ou un SonarQube.
Pour la même raison, SAST peut donner beaucoup de faux positifs - il est peu probable que les développeurs veuillent analyser un tas de chutes chaque jour après la prochaine analyse.
Habituellement, SAST est lancé sur la base de code pour la première fois, et la première exécution peut montrer beaucoup d'opérations, surtout s'il y a beaucoup de code et que la base de données n'est pas très nouvelle.

Tous les problèmes peuvent être résolus. Dans le prochain article de la série, nous examinerons, à l'aide d'un exemple concret de notre expérience, comment implémenter SAST de manière à niveler toutes ses fonctionnalités techniques et à rendre tout le monde heureux.

Questions d'organisation

Je n'oublierais pas les problèmes d'organisation. Dans les grandes entreprises, beaucoup d'entre elles découlent, du processus de mise en œuvre lui-même, de l'allocation des ressources à l'élaboration des réglementations et à la réplication des processus.

Les problèmes d'organisation sont générés par les mêmes caractéristiques techniques que nous avons discutées dans le paragraphe précédent. Eh bien, en plus de cela, la division et la confrontation historiquement établies entre le développement et la sécurité n'ont pas encore disparu. Je me réfère également à notre article précédent.

À suivre

Mettre en œuvre SAST - c'est nécessaire, c'est généralement justifié. Mais, en commençant à mettre en œuvre, ce serait bien de se familiariser avec tous les pièges qui se présentent sur votre chemin. Dans cet article, nous avons commencé à les démonter, nous continuerons avec les aspects techniques dans la suite.

(S) SDLC, ou Comment rendre le développement plus sûr. Partie 1