• Accueil / Salesforce / Pourquoi SAST n’est…
, Pourquoi SAST n&rsquo;est pas rapide pour DevOps<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Pourquoi SAST n’est pas rapide pour DevOps1 minutes de lecture


L’analyse du code source ou les tests statiques de sécurité des applications (SAST) sont une méthodologie qui analyse le code pour trouver les vulnérabilités de sécurité qui rendent vos applications vulnérables aux attaques et aux violations de données.

SAST est une première étape clé dans la sécurité des applications et le passage de DevOps à DevSecOps. SAST vous permet de détecter les vulnérabilités dès le début de la phase de développement, en analysant votre code source avant le test, le déploiement et la publication. Toute vulnérabilité détectée et corrigée au cours du développement permet d’économiser de l’argent au cours des itérations en cours et réduit considérablement le risque de violation de la sécurité.

, Pourquoi SAST n&rsquo;est pas rapide pour DevOps<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Développement lent des Blizzards SAST

Avez-vous déjà essayé de conduire vite dans un blizzard ? C’est presque impossible parce que votre vision est sévèrement limitée. Le SAST autonome crée un handicap similaire pour les développeurs Salesforce en raison du volume considérable de faux positifs créés, ce qui leur fait perdre un temps précieux et augmente le temps nécessaire pour corriger les véritables vulnérabilités de sécurité.

SAST manque la marque pour la sécurité

Les outils SAST sont connus pour générer des taux élevés de faux positifs, car l’analyse du code source doit pécher par excès de prudence pour détecter toutes les vulnérabilités potentielles. Pour être juste, la plupart des outils SAST autonomes n’ont pas été spécialement conçus pour détecter les vulnérabilités de sécurité des applications Salesforce. En règle générale, soit vous obtenez un scanner de qualité de code pour Salesforce auquel des règles de sécurité ont été ajoutées après coup, soit vous vous retrouvez avec un outil SAST polyvalent créé pour deux douzaines d’autres langues, en plus d’Apex. Indépendamment de cela, SAST n’est qu’une analyse de code et les faux positifs sont un résultat naturel.

Les développeurs utilisant les outils SAST sont généralement obligés de parcourir des listes interminables de faux avertissements positifs. Ils évaluent et classent les résultats un par un  jusqu’à ce qu’à un moment donné, les avertissements commencent à être ignorés à mesure que les développeurs deviennent fatigués.

Pour limiter cette tempête de fausses alarmes, SAST doit être associé à un moteur de test d’exécution pour effectuer des tests interactifs de sécurité des applications (IAST). IAST peut être utilisé pour vérifier l’exploitabilité de la plupart des résultats SAST, traçant chaque vulnérabilité pendant l’exécution, prouvant automatiquement qu’il ne s’agit pas d’un faux positif. IAST peut également détecter les failles d’injection critiques, telles que les vulnérabilités de script intersite (XSS) ou SOQL, qui peuvent souvent être ignorées par SAST seul.

De plus, regarder votre code source seul n’aide pas si vous avez des bibliothèques de logiciels open source tierces qui sont devenues non sécurisées en raison d’une faille de sécurité signalée publiquement ou de vulnérabilités et expositions communes (CVE). Pour atténuer ce risque de sécurité de la chaîne d’approvisionnement logicielle de plus en plus courant, SAST doit être intégré à l’analyse de la composition logicielle (SCA) pour détecter les vulnérabilités logicielles tierces non corrigées.

Salesforce DevSecOps : testez tôt, testez souvent, testez en continu

En fin de compte, la sécurité est un processus, pas un objectif final. La meilleure solution pour une sécurité complète des applications consiste à intégrer en profondeur vos outils de test de sécurité dans votre processus Salesforce DevOps pour obtenir des DevSecOps efficaces et efficients. Si Salesforce DevSecOps est implémenté correctement, cela réduit considérablement le coût de la correction des bogues, sans parler du fait qu’il réduit également considérablement les risques.

, Pourquoi SAST n&rsquo;est pas rapide pour DevOps<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Un cycle de vie de développement logiciel (SDLC) mature exploite les tests de sécurité à plusieurs points du pipeline CI/CD, en commençant par votre IDE, puis à chaque validation et au-delà dans les phases de déploiement. Si vous « virez à gauche » et testez les problèmes de sécurité tôt, souvent et régulièrement, votre SAST peut être rapidement et étroitement intégré à d’autres méthodologies de test de sécurité pour assurer la sécurité de votre Salesforce et de vos données.

, Pourquoi SAST n&rsquo;est pas rapide pour DevOps<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Résumé

Que pensez-vous de SAST ? Avez-vous connu des retards de développement dus à des problèmes liés au SAST, tels que des taux élevés de faux positifs ? Faites-nous savoir en laissant vos commentaires ci-dessous dans le champ de réponse.



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer