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.

Vibe Coding: Are Humans an asset or a threat?

As usual, our people are our salvation

We’ve seen cybersecurity evolve: from basement script kiddies to AI-fueled threats. And yet as we enter late 2025, Alan Shimel’s article “Distraction is the New Zero‑Day: The Human Risk We Keep Ignoring” rings truer than ever. It’s not ransomware or deepfake scams causing the most damage: it’s good old distraction. According to KnowBe4 research, 43 % of breaches are traced back to employee distraction, outpacing training gaps (41 %), pressure to act fast (33 %), fatigue (31 %), and even the sophistication of the threats (17.1 %) (Security Boulevard).

That’s a stark reminder: no matter how advanced your tech, if people are juggling too much, security unravels.

Enter vibe coding: how some teams will distinguish themselves. It’s not just a buzzword. It’s code being co‑authored by AI copilots like Microsoft Copilot, Claude, or ChatGPT. This new paradigm has arrived, and it's not just changing how we write code: it’s shaking up how security must be woven in. After all, we aren't there to slow you down in your endeavors.

Our processes are our weapons.

Here’s how we bridge that gap:

• Humans stay in control. AI is a tool, not an operator. It can craft and suggest: but accountability remains decidedly human.
• Security belongs in the flow. AI accelerates development: but without thoughtful guardrails, it opens doors for blind spots. We bake in safe defaults, code reviews, prompts that call out risky patterns.
• Awareness is the ultimate defense. In a distracted, hyper‑speed environment where AI suggestions flood the screen, our attention becomes the firewall. As Shimel cautions, distraction is the real zero‑day. Let’s guard against that, not just bug fixes.

At JPSoftWorks, we don’t just welcome vibe coding: we help organizations use it wisely. Because in a world where AI supports coding, the strongest security asset remains human intuition: if given the space, context, and tools to do its thing.

L'humain dans le "vibe coding": Un atout ou un risque additionnel?

L'les personnes à la rescousse

Nous avons vus la cybersécurité évoluer: from des pirates amateurs aux menaces IA. Mais fin 2025, l’article d’Alan Shimel "Distraction is the New Zero‑Day : The Human Risk We Keep Ignoring" résonne clairement. Ce ne sont ni les ransomwares ni les deepfakes qui causent le plus de dégâts: c’est la distraction. D’après une étude KnowBe4, 43 % des incidents sont liés à la distraction des employés, quand le manque de formation atteint 41%, la pression 33%, l’épuisement 31%, et la sophistication des attaques seulement 17,1% (Security Boulevard, IT Pro).

Un signal fort: peu importe la robustesse de vos technologies, si les gens sont surchargés, la sécurité se fissure.

Voici comment nous abordons cela via le vibe coding, version 2025 chez JPSoftWorks: Ce n’est pas un simple terme tendance. C’est du code co-réalisé avec des copilotes IA comme Microsoft Copilot, Claude ou ChatGPT. Une nouvelle ère du développement est là, et elle impose de repenser la sécurité. Après tout on est pas là pour tenter de freiner vos élans.

Les processus sont nos défenses.

Notre approche :

• L’humain garde la main. L’IA est un outil, pas un décideur. Elle peut suggérer ou rédiger: mais la responsabilité reste humaine.
• La sécurité fait partie du flux. L’IA accélère l’écriture, mais sans garde-fous, elle laisse des angles morts. On intègre des prompts sûrs, des revues de sécurité, des configurations défensives.
• La conscience humaine est la vraie protection. Dans un monde où la distraction nous guette et les suggestions IA pullulent, notre attention devient le pare-feu. Comme Shimel l’alerte, la distraction est la faille zéro. Préservons-la, pas seulement les patchs.

Chez JPSoftWorks, on ne se contente pas d’adopter le vibe coding: on aide les équipes à l’utiliser correctement. Parce que dans un monde où l’IA assiste le code, l’atout sécurité le plus solide reste l’intuition humaine: à condition qu’on lui donne l’espace, le contexte et les outils.

AI Code Generation: Superpower or Security Blindfold?

 At JPSoftWorks, we like to say: “Speed without security is just chaos with better sneakers.”

The rise of AI-powered code assistants has been breathtaking. A third of organizations already generate most of their code through AI, yet fewer than one-in-five have actual policies for how to use these tools. That’s like building a skyscraper with a jetpack: impressive to watch, terrifying for those inside.

The numbers are stark:

• 98% of organizations experienced code-related breaches this past year (up from 91%).
• Over 80% knowingly shipped vulnerable code to production.
• In North America, only 51% of orgs say they’ve adopted DevSecOps practices at all. (It's less in the Montreal metropolitan area: 30%).*

It isn’t hard to see the problem. AI is turbocharging our pipelines, but without security guardrails, it’s pouring fuel onto already smoldering vulnerabilities.

Where AI Meets SecDevOps (and Stumbles)

AI assistants can suggest code that “works,” but rarely code that works securely. Input validation? Dependency hygiene? Secure defaults? Often left out. And when developers trust the machine too much, we get what we call “vibe-driven coding.” It compiles, it runs, it even looks elegant, until someone discovers it also opens a backdoor.

The JPSoftWorks Take:

From our perch, the fix isn’t to throw away AI. It’s to govern it.

• Tag & Track AI-generated code: Know what came from the bot, and treat it with extra suspicion.
• Shift-Left Security: Plug SAST, DAST, IaC scans right into your CI/CD pipeline, before code hits prod.
• Human Review is Non-Negotiable: An AI can’t be accountable. Your devs can. Put human reviews in the pipeline as well.
• Secure Prompting: Teach teams to request security-aware outputs (“with input validation,” “using parameterized queries”).
• Policy, Policy, Policy: No more Wild West AI. Organizations need to set boundaries on how assistants are used.

Closing Thought

AI is the intern who types really, really fast. It doesn’t know your compliance frameworks, it doesn’t care about your threat model, and it has no sense of shame when it hands you vulnerable code. That’s your job.

Don't wait until your shop become the source of a breach. Let’s use the jetpack, but with a parachute, a helmet, and a solid flight plan.

Links:
AI Code Generation Creates Blind Spots in DevSecOps

Génération de code par IA : super-pouvoir ou bandeau sur les yeux de la sécurité?

 Chez JPSoftWorks, on aime dire : « La vitesse sans sécurité, c’est juste du chaos en baskets neufs. »

La popularité des assistants de code propulsés par l’IA est fulgurant. Un tiers des organisations génère déjà la majorité de leur code ainsi, mais moins d’une sur cinq a des politiques d’encadrement. C’est un peu comme construire un gratte-ciel avec un “jetpack”: spectaculaire à voir, anxiogène pour ceux à l’intérieur.

Les chiffres parlent d’eux-mêmes :

• 98 % des organisations ont subi des brèches liées au code l’an dernier (contre 91 %).
• Plus de 80 % expédient sciemment du code vulnérable en production.
• En Amérique du Nord, seulement 51 % des organisations affirment avoir adopté le DevSecOps. (Cette statistique se dégrade dans la région métropolitaine de Montréal ~30%)*

L’équation est simple : l’IA accélère nos pipelines, mais sans garde-fous, elle jette de l’essence sur des braises déjà ardentes.

Là où l’IA et le DevSecOps se croisent (et trébuchent)

Les assistants IA proposent du code qui “marche”, mais rarement du code qui fonctionne en toute sécurité. Validation des entrées ? Hygiène des dépendances ? Paramètres sécurisés ? Souvent oubliés. Et lorsque les développeurs font trop confiance à la machine, on tombe dans ce que nous appelons le « vibe coding ». Ça compile, ça roule, ça a même l’air élégant, jusqu’à ce qu’on découvre que ça ouvre aussi une porte arrière.

La vision JPSoftWorks

Notre approche SecDevOps n’est pas de bannir l’IA, mais de l’encadrer :

• Étiqueter et suivre le code généré par IA : savoir d’où il vient, et le vérifier deux fois.
• Sécurité “Shift-Left” : intégrer SAST, DAST, IaC directement dans vos pipelines CI/CD.
• La revue humaine est obligatoire : l’IA n’est pas responsable, vos devs le sont. Et on ajoute ca dans le pipeline.
• Prompts sécurisés : apprendre aux équipes à demander explicitement des sorties sécurisées (« avec validation des entrées », « requêtes paramétrées », etc.).
• Politiques, politiques et encore politiques, claires : fini le Far West. Les organisations doivent définir des règles d’usage.

Mot de la fin

L’IA est le stagiaire qui tape vraiment, vraiment vite. Mais elle n’a aucune notion de conformité, aucun modèle de menace, et pas la moindre honte à livrer du code vulnérable. Ce rôle vous revient.

N'attendez pas que le code qui sort de votre boîte soit la source d'une brèche. Utilisons le jetpack, mais avec un parachute, un casque, et surtout un bon plan de vol.

Liens:
AI Code Generation Creates Blind Spots in DevSecOps (Anglais)

90 % d’économies avec 5 lignes de code!

L'IA dans SecDevOps: pourquoi les "hacks de coûts" ne sont pas toute l'histoire

Je lisais un article de towardsdatascience.com. Et il m'est venu à l'esprit que la plupart d'entre nous seraient tentés de se lancer dans cette situation à l'aveuglette. Voici mon point de vue, sur ce qui en est.

"Comment nous avons réduit les coûts de LLM de 90% avec 5 lignes de code". À première vue, ce genre d'histoire est captivant: cinq lignes de code, 90% d'économies, comment ne pas adorer?

Mais lorsque nous regardons les choses à travers le prisme de SecDevOps, le récit devient plus complexe. Le coût n'est pas la seule variable qui compte dans une pratique sûre, résiliente et fiable.

*L'image est générée par l'IA

La tentation des solutions rapides

L'article décrit comment les développeurs ont utilisé la troncage de "réponse" avec leurs modèles de langage à grande échelle (LLM) pour réduire l'utilisation des jetons et réduire les coûts. Cela fonctionne bien dans les expériences à portée étroite ou les POC (preuves de concept). Mais dans les environnements SecDevOps: où les systèmes de production gèrent des flux de travail critiques pour la sécurité : les gains rapides s'accompagnent souvent de risques cachés :

• Angles morts opérationnels: Tronquer les réponses du modèle peut réduire les coûts, mais cela risque également de supprimer le contexte, les journaux ou les alertes de sécurité essentiels.
• Les LLM dans les pipelines d'opérations de sécurité peuvent gérer la télémétrie sensible. Toute stratégie d'optimisation doit être validée par rapport à la confidentialité des données et à la conformité réglementaire.
• Que se passe-t-il si une optimisation interrompt silencieusement un flux de travail de réponse aux incidents à 2 h du matin?

En bref: épargner 90% aujourd'hui ne signifie pas grand-chose si vous compromettez 99% de la confiance du système demain.

La perspective de SecDevOps

Lorsque nous introduisons des outils d'IA dans nos pipelines, que ce soit pour le triage des journaux, l'analyse de code ou l'aide à la décision en matière de sécurité, nous devons appliquer la même rigueur que nous apportons à toute autre technologie. 

Quelques principes directeurs :

• Des mesures holistiques, pas seulement des coûts.
  Mesurez non seulement les économies d'argent, mais aussi l'exactitude de la réponse, la couverture de détection, le respect de la conformité et le temps de récupération des incidents.

• Dépendances de l'IA de modélisation des menaces
  Chaque "optimisation" devient une nouvelle surface d'attaque. Par exemple: un attaquant pourrait-il exploiter la troncature de sortie pour cacher une activité malveillante dans les journaux?

• Déploiement contrôlé
  Les techniques d'économie de coûts doivent d'abord être déployées dans des environnements non liés à la production (Dev > QA > Acceptance) avant d'atteindre la production: le même chemin discipliné que nous utilisons pour toute migration d'infrastructure en tant que code ou de base de données.

• Vérifiabilité par défaut
  Nous ne nous contentons pas d'optimiser; nous documentons. Chaque changement dans la façon dont l'IA est utilisée dans les pipelines doit être vérifiable, versionné et sujet à annulation.

Application pratique dans les pipelines

Chez JPSoftworks, voici comment nous intégrerions une telle technique en toute sécurité dans un pipeline de sécurité CI/CD :

1. Isoler les composants d'IA dans les services dockerisés 
    Assurez-vous que les demandes et les réponses de LLM sont transmises par un conteneur de services avec des limites, une journalisation et une surveillance appliquées.

2. Contrôle centralisé des politiques
   Utilisez IaC (Bicep, Terraform) pour définir des politiques autour de l'interaction LLM: ycompris la troncature maximale des jetons et les catégories de données autorisées.

3. Couche de vérification
   Introduire des étapes de validation (p. ex., somme de contrôle, vérifications d'exhaustivité basées sur les regex) avant que les systèmes en aval ne consomment la sortie du modèle tronqué.

Conclusion: Au-delà des 5 lignes de code

Les articles promettant des "économies de 90%" attirent l'attention: et ils devraient. Les coûts sont importants. Mais dans SecDevOps, le coût ne peut jamais être le seul axe d'optimisation. La sécurité, la fiabilité et la vérifiabilité doivent être de pair avec l'efficacité.

Chez JPSoftworks, nous croyons qu'il est important de permettre aux organisations d'adopter l'innovation sans compromettre la confiance. Les gains rapides sont les bienvenus, mais seulement lorsqu'ils sont bien intégrés dans les systèmes sécurisés et résilients qui assurent le fonctionnement des entreprises.

Liens (Anglais):
How We Reduced LLM Costs by 90% with 5 Lines of Code | Towards Data Science

Saving 90% of cost with five lines of code.

 

AI in SecDevOps: Why “Cost Hacks” Aren't the Whole Story

I was just reading an article by towardsdatascience.com. And it occurred to me that most of us would be tempted to jump into this pretty blindly. Here's my take on it.

“How We Reduced LLM Cost by 90% with 5 Lines of Code”. On the surface, this kind of story is exciting: five lines of code, 90% cost savings, what's not to love?

But when we look at it through the lens of SecDevOps, the narrative becomes more complex. Cost isn't the only variable that matters in a secure, resilient, and reliable practice.

*Picture is AI Generated

---

The Temptation of Quick Fixes

The article describes how developers used response truncation with large language models (LLMs) to reduce token usage and slash costs. This works well in narrowly scoped experiments or proof-of-concepts. But in SecDevOps environments: where production systems handle security-critical workflows: quick wins often come with hidden risks:

• Operational Blind Spots: Truncating model responses might cut costs, but it also risks cutting out essential security context, logs, or alerts.
• LLMs in security operations pipelines may handle sensitive telemetry. Any optimization strategy must be validated against data confidentiality and regulatory compliance.
• What happens if an optimization silently breaks an incident response workflow at 2 a.m.?

In short: saving 90% today means little if you compromise 99% of system trust tomorrow.

---

The SecDevOps Perspective

When we introduce AI tooling into our pipelines: whether for log triage, code analysis, or security decision-support: we must apply the same rigor we bring to any other technology.

Some guiding principles:

• Holistic Metrics, Not Just Cost.
  Measure not only dollar savings, but also response accuracy, detection coverage, compliance adherence, and incident recovery time.

• Threat Modeling AI Dependencies
   Every “optimization” becomes a new attack surface. For example: could an attacker exploit output truncation to hide malicious activity in logs?

• Controlled Deployment
  Cost-saving techniques should first roll out in non-production environments (Dev → QA → Acceptance) before reaching Production: the same disciplined path we use for any infrastructure-as-code or database migration.

• Auditability by Default
  We don't just optimize; we document. Every change in how AI is used within pipelines must be auditable, versioned, and subject to rollback.

---

Practical Application in Pipelines

At JPSoftworks, here's how we would integrate such a technique safely into a CI/CD security pipeline:

1. Isolate AI Components in Dockerized Services
    Ensure LLM requests and responses are mediated through a service container with enforced limits, logging, and monitoring.

2. Centralized Policy Control
   Use IaC (Bicep, Terraform) to define policies around LLM interaction: including max token truncation and allowable data categories.

3. Verification Layer
   Introduce validation steps (e.g., checksum, regex-based completeness checks) before downstream systems consume truncated model output.

---

Conclusion: Beyond the 5 Lines of Code

Articles promising “90% savings” capture attention: and they should. Cost matters. But in SecDevOps, cost can never be the only axis of optimization. Security, reliability, and auditability must stand shoulder to shoulder with efficiency.

At JPSoftworks, we believe in enabling organizations to embrace innovation without compromising trust. Quick wins are welcome: but only when they are integrated thoughtfully into the secure, resilient systems that keep businesses running.

---

Links:
How We Reduced LLM Costs by 90% with 5 Lines of Code | Towards Data Science

EAC or everything as code

 

Everything as Code: The Backbone of a Reliable, Secure, and Consistent DevSecOps Practice

At JPSoftWorks, you know, we've always believed that technology should serve people first: not the other way around. Over the years, working in SecDevOps, one truth has become increasingly clear to us: in order to create secure, maintainable, and high-quality systems, you need uniformity. And uniformity doesn’t happen by accident. It happens because you deliberately build it into your processes.

For us, one of the most powerful enablers of that uniformity is the philosophy of "Everything as Code" (EaC).

This isn’t just a catchy slogan or a trendy buzzword. It’s a disciplined approach that treats every element of your product lifecycle: application code, infrastructure, configurations, policies, pipelines, documentation, and even compliance checks: as version-controlled, reviewable, and testable artifacts.

And when you combine this philosophy with a solid Git-based branching and merging process, you unlock a level of consistency, traceability, and automation that fundamentally changes how you deliver value.

---

What "Everything as Code" Really Means

The simplest way to explain "Everything as Code" is:

If it can be expressed in a file, it belongs in version control. Ideally in a format that is friendly to content compares.

That means:

• Application code: of course, but also…
• Infrastructure as Code (IaC): Bicep, Terraform, ARM templates, Ansible playbooks, etc.
• Configuration as Code (CaC): Kubernetes manifests, application settings, feature flags.
• Policy as Code (PaC): Security and compliance rules, e.g., Open Policy Agent (OPA), Azure Policy definitions.
• Documentation as Code: Markdown, reStructuredText, or AsciiDoc files stored alongside the project.
• Pipeline as Code: CI/CD workflows in YAML (Azure DevOps, GitHub Actions, GitLab CI).
• Test definitions: Unit tests, integration tests, performance tests, and security scans scripts.
• Monitoring and alert definitions: Grafana dashboards, Prometheus rules, Azure Monitor alert definitions.

This approach eliminates the "special snowflake" problem: where production works one way, dev works another, and nobody’s quite sure how staging was set up. When everything lives in Git, there’s a single source of truth.

---

Why Git Is the Glue That Makes It Work

"Everything as Code" is powerful, but it’s not enough on its own. You need a discipline around how changes enter your codebase. That’s where Git, and specifically a deliberate branching and merging strategy, comes in.

We have a simple principle:

No change reaches the main branch without deliberate review and automated verification.

Every update: whether it’s a new feature, a change to infrastructure, a tweak in a policy, or a line in the documentation: comes in via a branch and a pull request (PR). That PR is the checkpoint where we:

1. Review the change: human eyes on the code, by the right people.
2. Run automated checks: tests, security scans, policy validations.
3. Decide deliberately: to merge or not to merge.

It’s not just bureaucracy. This process is where we ensure that changes meet our standards for security, performance, compliance, and maintainability. It's one of the many ways, Security Developers and Operations, joion forces to arrive to a better quality product in record time.

---

Uniformity Through Review and Automation

An here's how it works.

When you have a Git/merge process in place, you build uniformity into your product for developers this has been a "no brainer".

This now becomes a practice spread in four key areas:

1. Product Consistency

Whether it’s application features or bug fixes, PR reviews ensure that:

• New code follows established patterns and coding standards.
• Functionality is consistent with business and user expectations.
• Security implications are addressed before code hits production.

Automated checks here might include:

• Compilation/build validation: make sure the code builds cleanly in a consistent environment.
• Unit tests: catch regressions early.
• Static code analysis: flag potential security vulnerabilities or bad practices (e.g., SonarQube, ESLint, Roslyn analyzers).
• Dependency scanning: identify vulnerable third-party packages.

2. Configuration Uniformity

Configuration drift is one of the biggest headaches in operations. With Configuration as Code:

• Your dev, QA, and production environments are built from the same base files.
• Any change in configuration goes through the same PR process.
• Rollbacks are as simple as reverting a Git commit.

Automated checks might include:

• Linting configuration files: e.g., yamllint, terraform validate.
• Policy compliance: Azure Policy, OPA checks in pipelines.
• Idempotency tests: ensuring rerunning the configuration doesn’t cause unexpected changes.

3. Documentation Alignment

By keeping documentation in the same repo as the code, you eliminate stale, irrelevant, or contradictory docs.

• PR reviewers can check that documentation updates match the actual feature or configuration change.
• Automated processes can even check for broken links or missing sections.
• Tools like mkdocs or Sphinx can automatically rebuild and publish updated documentation.

Automation here could include:

• Spellcheck/grammar check: automated linting for docs.
• Doc coverage checks: ensuring new features have accompanying documentation.
• Link validation: to ensure no outdated references.

4. Test Synchronization

Tests live alongside the code they validate. When you change a feature:

• The PR process requires updating or adding tests.
• Automated CI ensures those tests run on every change.
• Code coverage tools report if coverage has decreased.

This makes it impossible to "forget" to update tests because reviewers will catch it: and the pipeline will fail if the tests don’t pass.

---

The Automation Opportunities in the Merge Process

The pull request process is not just about human review. It’s also the perfect trigger point for automation. Our PR pipelines might run:

• Build & Compile: Verifying the code compiles in a clean environment.
• Unit Tests: Immediate validation of logic.
• Integration Tests: Ensuring services play well together.
• Static Code Analysis: Security and quality gates.
• Dependency Scans: SCA (Software Composition Analysis) to find vulnerable libraries.
• Infrastructure Validation: e.g., terraform plan or Azure ARM/Bicep "What-If".
• Policy Checks: Automated verification of security rules.
• Performance Baselines: Quick checks to ensure we haven’t introduced performance regressions.
• Compliance Verification: Automated SOC 2, ISO 27001, or internal policy checks.
• Container Image Scanning: Detect vulnerabilities in Docker images.
• Secret Detection: Prevent accidental commits of API keys or credentials.

This shift-left automation means issues are caught before they have a chance to impact production.

---

Security as an Embedded Outcome

Because everything goes through version control and PR review, we automatically embed security in the process:

• No undocumented changes: every change is tracked with commit history.
• No unauthorized changes: Git permissions enforce who can merge.
• Transparent audit trail: full visibility into who changed what and why.
• Security scans at PR time: so vulnerabilities are fixed before release.

In traditional environments, security is often a gate at the end of the pipeline. In "Everything as Code," security becomes part of the flow. This one of the key concepts.

---

Real-World Benefits

Implementing "Everything as Code" with disciplined Git processes gives JPSoftWorks and our clients:

• Fewer production incidents: because drift and undocumented changes are eliminated.
• Faster onboarding: new team members have the complete system described in code.
• Simpler audits: compliance evidence is in Git.
• Predictable deployments: what we tested is what we ship.
• Confidence in change: automated checks catch regressions early.

And perhaps the biggest benefit: trust. Teams trust the system because they know changes are deliberate, reviewed, and tested. Stakeholders trust delivery because they see a reliable track record.

---

Going Beyond: Future Opportunities

"Everything as Code" is not static. Here are some additional baby steps worth exploring:

• Automated threat modeling as part of PR pipelines.
• Self-healing infrastructure definitions that are triggered and adapt based on monitored metrics.
• AI-assisted PR reviews to flag potential issues faster.
• Unified observability as code: version-controlling dashboards and alert rules alongside application changes.

---

Conclusion

At JPSoftWorks, "Everything as Code" is more than a technical choice: it’s a cultural one. It says:

• We value transparency.
• We value deliberate change.
• We believe automation should amplify human expertise, not replace it.
• We believe that security, consistency, and quality are built in: not bolted on.

By combining the philosophy of "Everything as Code" with a disciplined Git-based merging process, we ensure that products, configurations, documentation, and tests evolve together: reviewed by the right people and validated by automation before they ever touch production.

That’s how we help create software that doesn’t just work today, but can be trusted tomorrow.

---

If you’d like to see how this approach can strengthen your own delivery processes: and secure them: let’s talk. At JPSoftWorks, we’re here to make tools and technology work for people, first. Contact Us