Théâtre de la sécurité infonuagique: pourquoi les "meilleures pratiques" d'Azure ne vous sécurisent pas réellement (Avec blogueur invité Joshua Copeland)

Seule, une "checklist" ne vaut rien.

Joshua Copeland et Jean-Paul Lizotte

Image générée par l'IA.

Tout le monde aime une liste de contrôle (checklist). Microsoft les publie. Les consultants facturent par eux. Les RSSI s'accrochent à eux. Mais voici ce qu'on pense discrètement, mais dit à haute voix: les meilleures pratiques Azure consistent davantage à réussir les audits qu'à arrêter les attaquants.

Ils ont fière allure dans un rapport du conseil. Ils cochent la case de conformité. Mais ils ne reflètent pas la façon dont les adversaires se œuvrent, exploitent et pivotent réellement dans les environnements infonuagiques. Ce qui nous reste, c'est le théâtre de la sécurité; l'illusion de la sécurité sans la substance de la résilience.

Le problème des "meilleures pratiques"

Les "meilleures pratiques" semblent réconfortantes. Ce sont les garde-fous brillants que les vendeurs vous tendent, la case que tout vérificateur veut cocher, la phrase à laquelle chaque dirigeant s'accroche lorsqu'il ne comprend pas vraiment le risque. Mais voici le problème: la plupart des meilleures pratiques Azure ne sont pas conçues pour arrêter les attaquants, du moins pas les attaquants d'aujourd'hui, elles sont conçues pour créer une apparence de sécurité. Ils normalisent le minimum, et non le maximum. Ils résolvent l'optique de la conformité, pas la pression de l'adversaire. Et lorsque les organisations les traitent comme un évangile, elles finissent par construire des systèmes fragiles qui semblent sûrs sur papier, mais qui s'effondrent au moment où quelqu'un décide de vraiment les tester.

Il s'agit de marketing, pas de sécurité.

La plupart des "meilleures pratiques" d'Azure sont écrites pour montrer à quel point la plateforme est soignée, et non comment elle résiste réellement aux attaques. Il s'agit de configurations généralisées et conviviales destinées à avoir fière allure dans une présentation PowerPoint ou à satisfaire à un audit de conformité. Le problème? Les vrais adversaires ne se soucient pas des tableaux de bord propres ou des politiques bien alignées. Ils recherchent les exceptions, les anciens comptes que personne n'a touchés, le directeur de service mal configuré qui tient tranquillement l'administration globale. Les meilleures pratiques créent l'illusion d'une forteresse, mais trop souvent c'est une découpe en carton... parfaite pour une démonstration de vente, inutile en cas de brèche.

Un jeu de chat et souris.

Au moment de la publication des directives, les attaquants ont déjà changé de tactique. Les kits de contournement de l'authentification multifacteur, le vol de jetons et les fédérations d'identités mal configurées ne sont pas abordés dans les PDF sur papier glacé. Lorsque les menaces changent quotidiennement, elles ne seront jamais exactes au paysage actuel des menaces.

Ils mesurent la conformité, pas la résilience.

Réussir un benchmark de sécurité Azure, c'est comme réussir un examen à livre ouvert. Cela ne prouve pas que vous pouvez performer sous pression; Cela prouve que vous pouvez lire et trouver les réponses. Ce n'est pas mal, mais n'importe qui peut cliquer sur une liste de contrôle, activer quelques bascules et générer un rapport indiquant "sécurisé". Mais cela ne signifie pas que votre environnement peut résister au vol de jetons, à l'élévation de privilèges ou à un déplacement latéral à travers une identité mal configurée. La conformité montre que vous avez suivi la recette. La résilience prouve que vous pouvez improviser lorsque l'alarme incendie se déclenche et que la recette ne s'applique plus. Les attaquants ne se soucient pas de savoir si vous avez obtenu un score de 100% sur un point de référence, ils se soucient des espaces que vous avez laissés entre les lignes.

Le point de vue de JP: Bâtir une résilience réelle

Les bonnes pratiques sont des enjeux importants. Ce qui compte, c'est comment vous renforcez le système contre les défaillances, la dérive et les compromis. Cela nécessite de concevoir pour les attaquants, et non pour les auditeurs :

• L'automatisation dans un souci de résilience. Ne vous contentez pas d'automatiser les bascules; Automatisez la récupération et l'auto-réparation. Les pipelines d'infrastructure qui détectent la dérive et corrigent automatiquement réduisent votre surface d'attaque plus rapidement que les correctifs manuels.
• L'examen par les pairs comme contrôle de sécurité de première classe. Les déploiements automatisés nécessitent des frictions humaines aux bons endroits. L'examen par les pairs des changements d'architecture et des demandes de tirage IaC détecte les types d'erreurs qui mènent à l'élévation des privilèges. C'est moins tape-à-l'œil qu'un tableau de bord, mais beaucoup plus efficace.
• Protection des données sur le terrain. Le chiffrement des disques et des objets blob est évident. Le chiffrement des champs sensibles dans les bases de données et les flux de messages est ce qui frustre les attaquants. Même s'ils pivotent, ce qu'ils tirent est inutile sans clés.
• Exploitation forestière résiliente. Si vos journaux ne vivent que dans le même locataire que vous défendez, ils sont à un rm -rf de disparaître. L'expédition des journaux dans un environnement isolé garantit que vos services judiciaires survivent à l'atteinte.

 C'est ainsi que vous passez du théâtre à l'ingénierie de la résilience.

Au-delà de la liste de contrôle: ce qui fonctionne réellement

Bases de référence axées sur les menaces

• Analyse des journaux.
• Enregistrez tout et ayez des outils qui analysent ces journaux pour détecter des modèles "inhabituels" répétés, y compris le volume d'accès.
• Examinez fréquemment les registres.
• Utilisez des pots de miel (honeypots) ou des ressources de tromperie pour détecter rapidement les sondages d'identité et les attaques brutes d'identifiants.
• Alternez régulièrement les secrets et les clés des principaux de service, l'automatisation appliquant les horaires de rotation.
• Créez des tableaux de bord de comportement "normaux" de base et alertez sur les tendances des écarts plutôt que sur des seuils bruts.
• Tirez parti de l'IA pour signaler les tendances ou les indices cachés. Mais ne vous y fiez pas!

 Contrôles du  périmètre de l'abus d'identité

• Prenez le temps d'y accéder. 
• L'accès anonyme devrait être refusé à la frontière. 
• Appliquez des politiques d'accès conditionnel qui évaluent la posture des appareils, l'emplacement du réseau et l'analyse comportementale.
• Limitez l'accès "juste-à-temps" avec une expiration automatisée pour les rôles élevés (Privileged Identity Management dans Azure AD).
• Cartographiez et élaguez les "identités fantômes" (comptes de service, utilisateurs invités obsolètes) à une cadence mensuelle.

  Automatisation et responsabilisation

• Tous les changements ont une intégration automatisée (CI). 
• Les résultats sont examinés par les pairs et signés par eux.
• Appliquer « l'intégrité à deux personnes" pour les changements d'infrastructure sensibles: l'automatisation promulgue le changement, mais un deuxième pair signe numériquement.
• Liez chaque modification d'infrastructure à un élément de travail ou à un ticket – le pipeline CI devrait échouer s'il ne peut pas lier la modification de code à l'intention.
• Conservez des pistes d'audit immuables des actions d'automatisation dans un magasin de journaux externe (p. ex., blob d'ajout seul ou connecteur SIEM).

 Rapports de conformité sur les tests de résilience : 

• Authentification et tests d'identité
• Autorisation et contrôle d'accès
• Protection des données et confidentialité
• Configuration infonuagique et tests d'infrastructure
• Sécurité des applications (OWASP + infonuagique spécifique)
• Sécurité des réseaux et des API
• Conformité et chaîne d'approvisionnement
• Analyse de code (Snyk, Sonarqube)
• Stockez les résultats dans un stockage cloud séparé, mettez en évidence tout changement de statut. 
• Effectuez des exercices qui simulent le vol de jetons, les mouvements latéraux ou la corruption des journaux: mesurez le temps nécessaire pour détecter et réagir.
• Intégrez l'ingénierie de sécurité du chaos: par exemple, injectez délibérément des certificats expirés, des jetons révoqués ou désactivez l'authentification multifacteur pour tester si la détection et la récupération se déclenchent.
• Testez la survie des données: simulez la perte de journaux de production et confirmez que votre environnement secondaire d'expédition de billes reste intact.
• Automatisez l'équipe rouge dans une boîte: les analyses planifiées et les tentatives d'élévation de privilèges scritées s'exécutent en continu, avec des résultats intégrés au backlog.
• Encore, tirez parti de l'IA pour signaler les tendances ou les indices cachés. Mais ne vous y fiez pas!

Les responsables de la sécurité aiment se vanter de "suivre les meilleures pratiques Azure". Les attaquants aiment que vous le fassiez aussi. Parce qu'ils savent que ces pratiques exemplaires n'ont pas été écrites pour eux. Ils ont été écrits pour vous vendre la tranquillité d'esprit.

Notre clôture

Les bonnes pratiques et les vérifications feront toujours partie du jeu. Ils ont posé le plancher, mais jamais le plafond. La vraie résilience survient lorsque vous allez au-delà des vérifications et que vous commencez à concevoir des systèmes pour survivre au contact avec les attaquants.

Cela signifie :

• Automatisez en pensant à la récupération: des pipelines qui non seulement se déploient, mais auto-réparent les infrastructures et détectent les dérives.
• Ajoutez des frictions humaines là où ça compte: évaluation par les pairs et intégrité de deux personnes pour les changements sensibles.
• Protégez les données qui comptent le plus : chiffrement au niveau du terrain, sauvegarde et journalisation de survie dans des magasins isolés.
• Testez l'échec, pas seulement la conformité: répétez les violations, semez le chaos et prouvez que vous pouvez vous remettre.

Les attaquants ne se soucient pas de votre note d'audit. Ils se soucient des fissures entre vos commandes. Combler ces lacunes est ce qui transforme le "théâtre de sécurité" en véritable résilience.

  La  vraie résilience commence lorsque vous cessez d'adorer les listes de contrôle et commencez à construire des systèmes que les attaquants détestent et que vous aimerez.

Cloud Security Theater: Why Azure "Best Practices" Don’t Actually Make You Secure (With guest blogger, Joshua Copeland)

Alone a checklist is worthless.

Joshua Copeland and Jean-Paul Lizotte

Image generated by AI.

---

Everyone loves a checklist. Microsoft publishes them. Consultants bill by them. CISOs cling to them. But here's the quiet part out loud: Azure best practices are more about passing audits than stopping attackers.

They look good in a board report. They check the compliance box. But they don't reflect how adversaries actually move, exploit, and pivot in cloud environments. What we're left with is "security theater"; the illusion of safety without the substance of resilience. It's all for show.

---

The Problem With "Best Practices"

"Best practices" sound comforting. They're the shiny guardrails vendors hand you, the box every auditor wants checked, the phrase every executive clings to when they don't really understand the risk. But here's the problem: most Azure best practices aren't actually designed to stop attackers, at least not today's attackers, they're designed to create the appearance of security. They standardize the minimum, not the maximum. They solve for compliance optics, not for adversarial pressure. And when organizations treat them as gospel, they end up building fragile systems that look secure on paper but crumble the moment someone decides to really test them.

They're marketing, not security.

Most Azure "best practices" are written to showcase how polished the platform looks, not how it actually holds up under attack. They're generalized, vendor-friendly configurations meant to look great in a PowerPoint deck or satisfy a compliance audit. The problem? Real adversaries don't care about clean dashboards or neatly aligned policies. They look for the exceptions, the legacy accounts no one touched, the misconfigured service principal quietly holding global admin. Best practices create the illusion of a fortress, but too often it's a cardboard cutout…perfect for a sales demo, useless in a breach.

They lag reality.

By the time guidance is published, attackers have already shifted tactics. MFA bypass kits, token theft, and misconfigured identity federations aren't addressed in the glossy PDFs. Standards be the vendor, industry, or government take months to years to formalize. When the threats are changing daily, they will never be accurate to the current threat landscape.

They measure compliance, not resilience.

Passing an Azure security benchmark is like acing an open-book exam. It doesn't prove you can perform under pressure; it proves you can read and can find the answers. That isn't bad, but anyone can click through a checklist, enable a few toggles, and generate a report that says "secure." But that doesn't mean your environment can withstand token theft, privilege escalation, or a lateral move through a misconfigured identity. Compliance shows you've followed the recipe. Resilience proves you can improvise when the fire alarm goes off and the recipe no longer applies. Attackers don't care if you scored 100% on a benchmark—they care about the gaps you left between the lines.

JP's Take: Building Real Resilience

Best practices are table stakes. What matters is how you harden the system against failure, drift, and compromise. That requires designing for attackers, not auditors:

• Automation with resilience in mind. Don't just automate toggles; automate recovery and self-healing. Infrastructure pipelines that detect drift and auto-correct reduce your attack surface faster than manual patching ever can.
• Peer review as a first-class security control. Automated deployments need human friction in the right places. Peer review on architecture changes and IaC pull requests catches the kinds of mistakes that lead to privilege escalation. It's less flashy than a dashboard, but far more effective.
• Field-level data protection. Encrypting disks and blobs is obvious. Encrypting sensitive fields inside databases and message flows is what frustrates attackers. Even if they pivot, what they pull is useless without keys.
• Resilient logging. If your logs live only in the same tenant you're defending, they're one rm -rf away from disappearing. Log-shipping to an isolated environment makes sure your forensics survives the breach.

This is how you move from theater to resilience engineering.

---

Beyond the Checklist: What Actually Works

Threat-driven baselines

• Log analysis.
• Log everything and have tools that analyse those logs for repeated "unusual" patterns including volume of accesses.
• Review the logs frequently.
• Use honeypots or deception assets to catch identity probing and credential stuffing early.
• Rotate service principal secrets and keys regularly, with automation enforcing rotation schedules.
• Build baseline "normal" behavior dashboards and alert on deviation rather than raw thresholds.
• Leverage AI to flag trends or hidden clues. But do not depend on it!

Identity abuse perimeter controls  

• Take the time to gate access. 
• Anonymous access should be denied at the border. 
• Apply conditional access policies that weigh device posture, network location, and behavioral analytics.
• Limit "just-in-time" access with automated expiration for elevated roles (Privileged Identity Management in Azure AD).
• Map out and prune "shadow identities" (service accounts, stale guest users) on a monthly cadence.

Automation with accountability

• All changes have an automated integration (CI). 
• The outcomes are reviewed by peers and signed off by them.
• Enforce "two-person integrity" for sensitive infrastructure changes: automation enacts the change, but a second peer signs off digitally.
• Tie every infrastructure change to a work item or ticket — the CI pipeline should fail if it can’t link the code change to intent.
• Keep immutable audit trails of automation actions in an external log store (e.g., append-only blob or SIEM connector).

Resilience testing Compliance reports: 

• Authentication & Identity Testing
• Authorization & Access Control
• Data Protection & Privacy
• Cloud Configuration & Infrastructure Testing
• Application Security (OWASP + Cloud Specific)
• Network & API Security
• Compliance & Supply Chain
• Code Scanning (Snyk, Sonarqube)
• Store the results in a separate cloud storage, highlight any changes in statuses. 
• Run tabletop exercises that simulate token theft, lateral movement, or log corruption — measure how long it takes to detect and respond.
• Integrate chaos security engineering: e.g., deliberately inject expired certificates, revoked tokens, or disabled MFA to test if detection and recovery trigger.
• Test data survivability: simulate loss of production logs and confirm your secondary log-shipping environment remains intact.
• Automate red team in a box: scheduled scans and scripted privilege escalation attempts run continuously, with results fed into backlog.
• Leverage AI to flag trends or hidden clues. But do not depend on it!

---

Security leaders love to brag about "following Azure best practices." Attackers love when you do too. Because they know those best practices weren't written for them. They were written to sell you peace of mind.

Our Close

Best practices and audits will always be part of the game. They set the floor, but never the ceiling. Real resilience comes when you move beyond passing checks and start designing systems to survive contact with attackers.

That means:

• Automate with recovery in mind: pipelines that not only deploy, but self-heal and detect drift.
• Add human friction where it counts: peer review and two-person integrity for sensitive changes.
• Protect the data that matters most: field-level encryption, backup and survivable logging in isolated stores.
• Test for failure, not just compliance: rehearse breaches, inject chaos, and prove you can recover.

Attackers don’t care about your audit score. They care about the cracks between your controls. Closing those gaps is what turns "security theater" into true resilience.

Real resilience starts when you stop worshipping checklists and start building systems that attackers hate and you will love.

---

With thanks to Joshua Copeland of Tulane University for his contributions to this article.

Imposer une technologie: un réflexe familier qu’il faut questionner

Un scénario qui se répète

Je pense qu'on set mettra d'accord: nous avons déjà vu ce scénario plusieurs fois. En ce moment, de nombreux développeurs expriment leur mécontentement à l’égard de GitHub Copilot, notamment parce qu’il devient compliqué de s’en défaire. Un récent article de The Register pointe deux discussions très suivies sur GitHub cette année: l’une demande à empêcher Copilot de générer des issues ou des pull-requests, l’autre réclame la possibilité de désactiver ses revues de code. C’est plus qu’un simple râle de forum ; c’est un malaise réel face à une solution imposée, renforcé par le fait que l’icône de Copilot revient sans cesse dans VS Code, même après désinstallation.

Le discours des géants technologiques

De l’autre côté, on retrouve le PDG de GitHub, Thomas Dohmke, qui adopte un ton radical: "adoptez l’IA… ou mettez-vous à la porte." Dans un billet de blog et lors de la conférence DLD, il a lancé un ultimatum clair: l’IA n’est plus optionnelle, celles et ceux qui ne s’y adaptent pas seront laissés pour compte. Ce discours s’aligne sur une stratégie fréquente des géants technologiques: pousser très fort un changement technologique, associer progrès et urgence, et s’attendre à ce que tout le monde suive.

Ce n’est pas la première fois. Qui s’en souvient ? Tout le monde avait râlé sur Windows 11… et pourtant, l’adoption sera massive. Chez JPSoftWorks, nous savons que les entreprises tech tendent naturellement à imposer ces virages, mais nous sommes convaincus qu’elles ont aussi une responsabilité, celle de respecter l’autonomie des développeurs et de rappeler que chaque choix technologique comporte son lot de compromis. Et ne commencez pas à discuter de compromis avec moi. ;)

Les limites d’un choix exclusif

Les critiques envers Copilot vont au-delà de l’interface. Des projets open-source comme Servo, FreeBSD, Loupe (GNOME), NetBSD, Gentoo ou QEMU ont purement et simplement exclu les contributions générées par l’IA, invoquant des risques liés à la fiabilité, aux licences ou à l’éthique. Ce n’est pas seulement une question juridique: la sécurité reste un enjeu majeur. Des études académiques montrent que, même si ces outils peuvent parfois égaler les performances humaines, ils génèrent encore des bouts de code vulnérables ou erronés.

Notre approche SecDevOps

Dans notre pratique de SecDevOps, nous reconnaissons ce dilemme. Nous voulons stimuler l’innovation tout en protégeant la confiance, la sécurité et l’éthique. Notre credo, c’est donc la décision éclairée. S’engager entièrement sur une seule technologie, ici l’automatisation par IA, peut sembler séduisant. Mais cela restreint les choix et crée des dépendances.

Une adoption responsable de l’IA

Cela ne signifie pas rejeter l’IA. Les gains de productivité sont réels. Certaines études évoquent des améliorations entre 30 % et plus de 50 % selon les cas. Le potentiel existe. L’essentiel, c’est comment on l’introduit. Est-ce que l’accompagnement est clair ? L’IA n’est-elle pas un assistant, mais bien un outil ? Identifions clairement où elle allège le travail et où l’intervention humaine reste incontournable.

Notre conclusion

il est peut-être normal, voire inévitable, que les entreprises technologiques imposent de nouveaux outils. C’est souvent comme ça que l’innovation se diffuse. Mais cela ne nous dispense pas de la vigilance. Chez JPSoftWorks, nous croyons à des choix technologiques audacieux, mais réfléchis. L’IA est brillante, mais pas universelle. Restons rigoureux, évaluons ses points forts comme ses limites, et restons prêts à rediriger nos choix si nécessaire.

Choisir la technologie avec audace et discernement, c’est ainsi que nous construisons des logiciels robustes et responsables.

Pushing Technology on People: A Familiar Pattern We Can’t Ignore

The Push from Technology Leaders

I think we can agree: we’ve seen this play out before. Right now, many developers are voicing frustrations with GitHub Copilot, particularly how it’s being imposed on users and how hard it is to simply opt out. A recent report in The Register highlights two of the most up-voted GitHub discussions over the past year: one calling for a way to block Copilot from generating issues and pull requests, and another demanding the ability to disable Copilot-driven code reviews. Community feedback is no small chorus. It reflects real discomfort about Copilot’s intrusiveness, including its automatic icon re-appearing in VS Code even after uninstalling the extension. Part of that frustration stems from users feeling forced into this tool, not because of its benefits, but because enormous companies made it hard to avoid.

On the flip side, we have GitHub’s CEO Thomas Dohmke stepping up the rhetoric: "embrace AI or get out." In a blog post and at the DLD conference, he dropped a clear ultimatum for developers: AI is no longer optional, and those who don’t adapt may be left behind. This isn’t theoretical. It reflects the way technology firms often roll out large-scale shifts: push forward aggressively, appeal to progress, and expect everyone to keep pace.

We’ve Seen This Before

This approach isn’t new. Remember when everyone groaned about Windows 11? Mass adoption will still follow. At JPSoftWorks, we recognize that tech companies naturally push new paradigms, but companies have responsibilities too. That includes respecting developers' autonomy and highlighting that technological choices come with trade-offs.
The Risks of Going All In

Developers' concerns about Copilot go beyond UI annoyance. Issues around code correctness, licensing, copyright, and ethics run deep. Many open-source projects like Servo, FreeBSD, GNOME’s Loupe, NetBSD, Gentoo, and QEMU have outright banned AI-generated code, citing those very risks. And it’s not only license worries. Security is nontrivial too. Academic studies show that although tools like Copilot can match humans or even outperform them in some areas, they still generate vulnerable or flawed code in many cases.

Our SecDevOps Viewpoint

At JPSoftWorks, our SecDevOps practice is built around that tension. We want to empower innovation without sacrificing trust, safety, or ethics. We advocate for balanced decision-making. Going "all in" on one technology, especially AI-powered automation, can feel expedient. But it also narrows options and introduces dependencies and limitations. And let's not start talking about compromises, shall we? ;)

Responsible Adoption of AI

That doesn’t mean ignoring AI. There are real productivity gains. Some studies show efficiencies ranging from around 30 percent to over 50 percent in certain tasks. Productivity gains are out there. What matters is how we implement these tools. Are we onboarding responsibly? Are we treating AI as a supplement, not a replacement? Do we clearly define when and where it helps, and when human judgment must reign?

Our conclusion

It may be normal, and even inevitable, that tech companies push new solutions aggressively. It’s part of how innovation scales. But that reality doesn’t absolve us from scrutiny. At JPSoftWorks, we believe in being deliberate about our technology stacks. We resist the "golden hammer" fallacy. Even if AI is shiny, it’s not the answer to everything. We must stay diligent, assessing strengths and limits, staying prepared to pivot if needed.

Choosing technology boldly and wisely is how we build resilient and responsible software.

Où ne pas automatiser : préserver la valeur humaine au cœur du SecDevOps

Le contact client: toujours humain en premier

On parle beaucoup d'automatisation dans le SecDevOps, et à juste titre. Elle permet d'aller plus vite, de réduire les erreurs et d'intégrer la sécurité à toutes les étapes du cycle de livraison. Mais nous avons aussi appris qu'il y a des limites. Certaines situations exigent la présence humaine, car la confiance, le jugement et la relation ne peuvent pas être programmés.

Voici quelques exemples où l'automatisation doit céder la place aux personnes.

C'est le point le plus essentiel. Lorsqu'un client subit une panne, un incident de sécurité ou un non-respect d'engagement de service, la communication doit être humaine. Bien sûr, les notifications automatiques sont utiles pour informer rapidement et parfois donner un premier aperçu. Mais ce message initial doit être identifié clairement comme automatisé.

La vraie valeur réside dans la suite. Les clients veulent savoir qu'une personne réelle a reconnu le problème, en comprend les impacts et s'engage à prendre des mesures concrètes. Trop d'automatisation dans ce domaine donne l'impression aux clients qu'ils ne sont qu'une donnée de plus dans un journal système. Ce n'est pas l'expérience que nous voulons offrir.

Les moments de responsabilité

Dans le SecDevOps, les échecs arrivent. Un déploiement peut mal tourner, une faille de sécurité peut passer inaperçue, ou un service peut tomber. Automatiser les alertes est utile, mais la responsabilité doit rester humaine.

Un message automatique peut dire "Service X est indisponible", mais seule une personne peut dire "Nous sommes désolés, nous comprenons ce que cela implique pour vous et voici nos prochaines actions". C'est ce passage de l'événement technique à l'engagement humain qui crée la confiance.

Les décisions à risque

Autre frontière claire: les décisions à fort enjeu. L'automatisation est parfaite pour détecter les anomalies, identifier une dépendance vulnérable ou bloquer un déploiement non conforme. Mais la décision de passer outre ou non doit appartenir à une personne.

Le risque est toujours contextuel. L'automatisation ne peut pas évaluer pleinement les priorités business, l'impact client ou les considérations éthiques. Elle doit éclairer la décision, pas la prendre.

La culture et le feedback

La culture d'équipe ne s'automatise pas. Des outils peuvent collecter des données ou produire des synthèses, mais l'essentiel reste la discussion entre personnes.

Chez JPSoftWorks, nous avons constaté que lorsque les boucles de feedback sont trop automatisées, les conversations perdent en richesse. Les métriques sont importantes, mais elles ne remplacent pas le dialogue.

L'éthique et la conformité

L'automatisation est précieuse pour collecter des preuves et vérifier la configuration des systèmes. Mais en cas de suspicion de non-conformité ou de dilemme éthique, c'est aux personnes d'évaluer et d'agir. La confiance repose autant sur le respect des règles que sur la capacité à démontrer du jugement et de la responsabilité.

Tracer la limite

Notre philosophie chez JPSoftWorks est claire: automatiser pour aller plus vite, mais jamais au détriment de la confiance. Dès qu'il est question d'empathie, de jugement ou de responsabilité, c'est aux humains d'entrer en scène.

C'est pourquoi nous combinons une automatisation puissante avec une approche résolument humaine. Nous libérons le temps des équipes grâce aux outils, afin que, lorsque la voix humaine compte vraiment, nous soyons présents.

Where Not to Automate: Keeping Human Value at the Core of SecDevOps

Customer Contact: People First and Always

We talk a lot about automation in SecDevOps, and with good reason. Automation lets us move fast, reduce errors, and scale security into every part of the delivery pipeline. But we've also learned the hard way that not everything should be automated. Some things demand the human touch, because trust, judgment, and relationships can't be scripted.

Let's look at a few places where automation should stop and people should step in.

This is the most important one. When a customer is affected by an outage, a security incident, or even a missed service level target, the conversation has to feel human. Yes, automated notifications are useful: they give customers awareness and sometimes even early insights. But that initial message should be clearly labeled as automated.

Where the real value comes in is the follow-up. Customers want to know that a real person has acknowledged the problem, understands its impact, and is taking responsibility for the next steps. If we rely too much on automation here, we risk making customers feel like they're just another line in a log file. That's not who we are, and it's not the kind of trust we want to build.

Accountability Moments

In SecDevOps, failures happen, it's expected. Deployments don't always go smoothly, vulnerabilities slip through, and systems can go down. When they do, it's tempting to automate every part of the response. But accountability requires a person.

An automated message can say, "Service X is unavailable," but only a person can say, "We're sorry, we understand what this means for you, and here's what we're doing about it." That shift from a system event to a human commitment is where accountability lives.

Risk Decisions

Another area where we draw the line is high-stakes risk decisions. Automation is great at flagging issues: a dependency with a critical CVE, a failed compliance check, or a deployment that doesn't meet policy. But when the question becomes, "Do we release this anyway?": that needs a human.

Risk is about context. Automation can't fully weigh customer impact, business priorities, or ethical concerns. We want automation to inform those decisions, not make them for us.

Culture and Feedback

Culture can't be automated. We can use bots to gather data about deployments or to summarize feedback from retrospectives, but the heart of the process: people being candid, listening to each other, and finding ways to work better together: has to stay human.

At JPSoftWorks, we've seen that when teams try to automate feedback loops too much, the conversation loses depth. Metrics are important, but they don't replace dialogue.

Ethics and Compliance

Automation plays a big role in compliance: collecting logs, checking configurations, running reports. But deciding what to do with those findings is not something we hand over to a bot. If there's a suspected violation, or an ethical concern about data use, people must be the ones to evaluate and respond. Trust is built not only on being compliant, but on showing judgment and responsibility.

Drawing the Line

Our philosophy at JPSoftWorks is simple: automate to accelerate, but never automate away trust. The line between the two is usually clear. If the situation calls for empathy, judgment, or accountability, people must be involved.

That's why our SecDevOps practice balances powerful automation with human-first principles. We automate the repetitive work so that when it's time for the human voice to matter, we have the time and space to bring it

Augmenter nos pipelines SecDevOps sur Azure avec des agents IA (2/2)

Ce que nous augmentons (en termes simples)

Nous travaillons avec Azure DevOps et Azure Cloud depuis assez longtemps pour connaître cette vérité: nos pipelines produisent déjà les données/réponses dont nous avons besoin, mais ils les cachent dans des journaux, des métriques et des alertes répartis dans les outils. Les agents de l’IA nous aident à assembler cette histoire. Dans cet article, nous partageons un modèle simple et concret que nous utilisons chez JPSoftWorks pour augmenter SecDevOps sur Azure avec des agents qui surveillent, corrèlent et conseillent, sans gêner l’équipe.

Où l’agent se branche

Notre base de référence nous semble familière : Azure Repos ou GitHub, Azure Pipelines pour CI/CD, portes de sécurité pour SCA/SAST/DAST et déploiements d’atterrissage dans Azure Kubernetes Service (AKS) ou Azure App Service. L’observabilité réside dans Azure Monitor et Application Insights, Defender pour le cloud et Microsoft Defender pour DevOps alimentant les signaux de risque. Cette pile est solide, mais les gens se noient toujours dans l’information. La couche d’agent renverse le scénario en faisant trois choses pour nous:

1. Enrichir : Capturez les sorties du pipeline, les journaux et les résultats de sécurité; ajoutez du contexte comme les validations récentes, les différences de dépendance, la dérive de l’infrastructure et les tickets de modification.
2. Corréler : Relier les symptômes aux causes probables. Par exemple, associez un pic de temps de déploiement à un crochet Helm nouvellement ajouté, ou associez une augmentation des vulnérabilités faussement positives à une mise à jour de la règle d’analyse.
3. Conseiller : Proposer des actions qui s’adaptent à nos garde-fous. Il peut s’agir d’ouvrir automatiquement une PR pour resserrer une politique Azure, de suggérer un changement de parallélisme de test ou d’escalader un incident réel au bon canal d’équipe de service.

Nous plaçons l’agent d’IA sur le chemin d’événement qui existe déjà dans Azure :

• Ingestion : Azure Pipelines publie des artefacts et des journaux de build/test dans Azure Blob Storage; les données de télémétrie sont transmises à Log Analytics via Azure Monitor et Application Insights. Les signaux de sécurité arrivent de Defender pour le Cloud et de Defender pour DevOps.
• Bus : Nous reflétons les événements clés dans Event Hubs (ou Service Bus) pour garder l’agent découplé du pipeline (important).
• Runtime de l’agent : un service léger sur Azure Functions ou un conteneur dans AKS s’abonne à ces événements.
• Raisonnement + politiques : L’agent utilise nos invites (prompts), règles et playbooks internes, et lorsque nous avons besoin de capacités LLM, nous appelons Azure OpenAI avec un ancrage strict sur notre propre base de connaissances dans Azure AI Search ou un compte de stockage privé.
• Action : L’agent réécrit les commentaires dans Azure DevOps (fils de discussion PR, résumés de pipeline), crée des branches Git avec des correctifs, file des éléments de travail ADO ou publie des alertes annotées dans Teams. Pour les problèmes d’exécution, il peut ouvrir un incident Sentinel avec des preuves enrichies.

Ce que cela change pour l’observabilité

• Des journaux bruts aux récits : Au lieu de cinq alertes dans cinq outils, nous obtenons un récit : « Le déploiement a ralenti de 34% depuis le 20 août après l’ajout d’OWASP ZAP à l’étape de publication; envisagez de paralléliser les analyses ou de définir la portée des cibles.
• Sensibilisation aux tendances : L’agent suit les lignes de base mobiles. Lorsque le temps de construction augmente de 5% par semaine pendant trois semaines, nous en entendons parler avant de le sentir.
• Priorisation de la sécurité : Les résultats sont classés en fonction de l’exploitabilité, de l’exposition et du rayon d’explosion. Un chemin critique sur un code mort ne saute pas la file d’attente sur un support sur un service Internet.
• Boucles de rétroaction : L’agent teste ses propres conseils. Si la réduction de la conservation des journaux nuit aux médico-légaux, elle annule la recommandation et explique pourquoi.

Un plan simple dans Azure

Voici un diagramme minimal que nous utilisons pour expliquer le modèle aux équipes. (cliquez pour agrandir)

 

Comment nous l’exploitons en toute sécurité

• Les limites des données d’abord : l’agent ne voit que ce qu’il doit. Nous étendons les requêtes Log Analytics par service et nous acheminons les secrets via Key Vault. Les appels de LLM sont privés, et la consignation rapide et de réponse est effacée.
• Expliquez, puis agissez : les conseils sont par défaut; les actions nécessitent soit un runbook avec des types de changements préapprouvés, soit une approbation humaine explicite dans la vérification de la demande de tirage ou du pipeline.
• Connaissances versionnées : Les playbooks qui guident l’agent sont versionnés comme du code et validés dans des pipelines non producteurs.
• Contrôle des coûts : Nous regroupons les événements, utilisons la génération augmentée de récupération uniquement lorsque cela est nécessaire et mettons en cache le raisonnement préalable pour les problèmes répétés.

Cas d’utilisation du jour 1:

1. Détecteur de dérive de pipeline : Alertez lorsque l’ordre des étapes, les conditions ou les budgets de temps changent considérablement; ouvrez un PR pour rétablir les normes.
2. Réducteur de bruit pour les analyses de sécurité : regroupez les doublons, supprimez les familles connues et reclassez-les par chemins d’exposition découverts à partir d’Azure Resource Graph.
3. Chien de garde SLO : surveillez les budgets d’erreurs à partir d’App Insights; si le taux d’utilisation dépasse la politique, l’agent met en pause les déploiements risqués et propose un retour en arrière avec des liens vers des traces défaillantes.
4. Coach en risque de dépendance : Lorsqu’un nouveau colis atterrit, l’agent vérifie les fenêtres de support et les vulnérabilités transitives, puis propose une solution de rechange ou une stratégie d’épinglage plus sûre.

Conclusion : nous conservons notre pile Azure existante. Nous ajoutons simplement un agent qui écoute plus attentivement, relie les points plus rapidement et nous pousse à prendre de meilleures décisions.