Showing posts with label zerotrustrisk. Show all posts
Showing posts with label zerotrustrisk. Show all posts

Tuesday, June 3, 2025

DevOps versus DevSecOps, an illustrated example.

So what’s the big deal about DevSecOps?

Why can’t you just explain it?
I can, but first we need to talk about DevOps.

Act I – DevOps, the culture. Not a person.

Contrary to many job ads, DevOps isn’t a title. It’s a way of working that dissolves the wall between those who build software and those who run it. Think of it as a kit of good habits:

  • Shared ownership: Dev and Ops solve problems together.
  • Automation: Let the pipeline handle repeatable work so humans focus on value.
  • Continuous feedback: Ship small, ship fast, break less.
  • Process before product: Tools only matter if they fit the people and the flow.

Teams that embrace this cultural shift ship faster and with fewer outages: something the DORA State of DevOps reports have measured for years.[1]

Rule of thumb
Do the right thing at the right time.
Simple to say, tricky to master.

Act II – Adding the SEC

All we do is extend the same mindset: if Ops belongs in the conversation from day one, so does Security. DevSecOps weaves security controls, tests and governance into every stage of the pipeline instead of treating them like an end-of-cycle audit.[2]

Act III – A walk through the pipeline

(Click the picture to enlarge.)



Figure 1 – Sample Dev + Sec + Ops pipeline.
Stage Why it exists Who it shields
Experiment Fail fast on a branch or local sandbox. Literally everyone else.
Dev Prove the change plays well with codebase, config & IaC. Fellow engineers, OPS.
QA Automated & exploratory tests, data seeding, basic gates. Testers and early adopters.
UAT Mirror prod as closely as budgets allow; performance & business acceptance. Business stakeholders.
Prod Final gate, release notes, infra diffs. Real customers & revenue.

Security questions ride along:

  • Experiment → Dev – Static analysis, secret scanning.
  • Dev → QA – Dependency checks, container image signing.
  • QA → UAT – Dynamic (DAST) tests, infra-drift detection.
  • UAT → Prod – Compliance artefacts, runtime policy enforcement, configuration concerns.

We didn’t add environments: we baked security into the ones we already have.

Act IV – The big DevSecOps change.

Ready for the twist?

We change … nothing.

Stages, people and cadence stay the same. What changes is the definition of done. Security requirements become first-class citizens—groomed, coded, tested and deployed beside features. It feels almost boring, which is exactly the point: security becomes routine, not roulette.

Conclusion – Why this matters, now!

  • High-performing teams that couple culture, automation and security outperform their peers on stability and speed.[1]
  • Regulators and customers expect proof of software supply-chain hygiene, continuously.
  • Talent retention improves when Ops & Security aren’t firefighting at 2 a.m.

Your call to action

  1. Invite security to the daily stand-up. Today. Zero slide decks required.
  2. Automate one pain-point. 
  3. Add one security gate: OwaspSAST, SCA or container scan, before the next sprint review.
  4. Share this article with a teammate and ask what “doing the right thing at the right time” means to them.

DevSecOps isn’t a new religion; it’s DevOps done right. Start small, iterate, and let security become as invisible, and indispensable as, version control.

Ready to drop that wall for good? Let’s ship, safely. Questions let's have it below.


References

  1. Google Cloud / DORA – State of DevOps Reports
  2. Red Hat – What is DevSecOps?
  3. AWS – DevSecOps Explained

© 2025 JPSoftWorks. All rights reserved.

DevOps et SecDevOps version illustrée

Alors, c’est quoi "la grosse affaire" avec DevSecOps ?

Pourquoi est-ce si difficile à expliquer ?
Je peux le faire, mais parlons d’abord de DevOps.

Acte I – DevOps, la culture qu’on ne peut pas simplement "embaucher"

Contrairement à bien des offres d’emploi, DevOps n’est pas un titre ou un rôle. C’est une façon de travailler qui fait tomber le mur entre celles et ceux qui créent les logiciels et celles et ceux qui le font tourner, qui l'exploitent. Pensez à DevOps comme si c'était un ensemble de bonnes habitudes :

  • Responsabilité partagée: Dev et Ops résolvent les problèmes ensemble.
  • Automatisation: Le pipeline prend en charge le répétitif ; les humains se concentrent sur la valeur.
  • Rétroaction continue: Livrer petit et vite, c’est moins risqué que tout livrer d’un coup.
  • Le processus avant l’outil: Les outils ne comptent que s’ils servent l’équipe et son flux.

Les équipes qui adoptent ce changement culturel livrent plus vite et avec moins d’incidents, comme le démontrent les rapports DORA State of DevOps année après année.[1]

Règle d’or
Faire la bonne chose au bon moment.
Simple à dire, difficile à maîtriser.

Acte II – Ajouter le SEC

On étend la même logique : si Ops est dans la discussion dès le jour 1, la Sécurité y a sa place aussi. DevSecOps intègre contrôles, tests et gouvernance de sécurité à chaque étape du pipeline, au lieu d’un audit final hors délais.[2]

Acte III – Parcours du pipeline

(Cliquez sur l’image pour l’agrandir .)

Figure 1 – Exemple de pipeline Dev + Sec + Ops.
Étape Pourquoi elle existe Qui elle protège
Expérimentation Échouer vite sur une branche ou dans un bac à sable local. Pratiquement tout le monde.
Dev Vérifier l’intégration avec le code, la config et l’IaC. Les autres ingénieurs.
QA Tests automatisés et exploratoires, jeux de données, portes de contrôle. Testeurs et premiers utilisateurs.
UAT Imiter la prod autant que le budget le permet ; perf. et validation métier. Parties prenantes d’affaires.
Prod Dernière porte, notes de version, écarts d’infrastructure. Clients réels et revenus.

Les questions de sécurité voyagent avec l’application :

  • Expérimentation → Dev — Analyse statique, détection de secrets.
  • Dev → QA — Vérif. de dépendances, signature d’images conteneurs.
  • QA → UAT — Tests dynamiques (DAST), détection de dérive infra.
  • UAT → Prod — Artefacts de conformité, politiques à l’exécution.

Nous n’avons pas ajouté d’environnements: nous avons "scotché" la sécurité dans ceux qui existaient déjà.

Acte IV – Le grand changement DevSecOps.

Prêt·e pour le punch ?

On ne change… rien.

Les étapes, les gens et la cadence restent les mêmes. Ce qui change, c’est la définition de “fait” (Definition of done, ou DoD). Les exigences de sécurité deviennent des citoyens de première classe: planifiées, codées, testées, déployées avec les fonctionnalités. Ça paraît presque ennuyeux ; c’est justement le but : la sécurité devient routine, pas roulette russe.

Conclusion – Pourquoi c’est crucial maintenant

  • Les équipes qui combinent culture, automatisation et sécurité surpassent leurs pairs en stabilité et vitesse.[1]
  • La gouvernance, les lois et les clients exigent désormais une hygiène de la chaîne de livraison logicielle, en continu.
  • La rétention des talents s’améliore quand Ops et Sécurité ne sont pas en mode incendie à 2 h du matin.

Votre appel à l’action:

  1. Invitez la sécurité au stand-up quotidien. Dès aujourd’hui. Pas besoin de diapos.
  2. Automatisez une "épine dans le pied"
  3. Ajoutez un seul contrôle de sécurité: Owasp, SAST, SCA ou scan de conteneur, avant la prochaine revue de sprint.
  4. Partagez cet article avec un·e collègue et demandez-lui ce que « faire la bonne chose au bon moment » signifie pour elle ou lui.

DevSecOps n’est pas une nouvelle religion ; c’est du DevOps bien fait. Commencez petit, itérez, et laissez la sécurité devenir aussi invisible, et indispensable, que Git.

Prêts·es à faire tomber le mur pour de bon ? Livrons, en toute sécurité. Laissez vos question ci-bas!


Références

  1. Google Cloud / DORA – Rapports « State of DevOps »
  2. Red Hat – Qu’est-ce que DevSecOps ?
  3. AWS – DevSecOps expliqué

© 2025 JPSoftWorks. Tous droits réservés.

Monday, June 2, 2025

SecDevOps ou pas SecDevOps? C'est même pas une question!

SecDevOps + Zero-Trust : guide coquin pour les équipes qui « font déjà du DevOps »… ou pas !

TL;DR  On ne cherche pas à remplacer DevOps; on l'enveloppe dans une armure fluo qui bloque ou révèle le risque, tout en laissant la gang à l’intérieur danser comme si c'etait 1999.


Qu’est-ce que SecDevOps, au juste ?

  • DevOps : faire circuler la valeur vite, apprendre, recommencer (« vraiment TLDR »).
  • SecDevOps : même chose, mais on branche des capteurs de risques dans la plomberie pour que le danger avertit avant de mordre. (Encore plus de shift-left !)
  • Zero-Trust : « Ne jamais faire confiance, toujours vérifier »… appliqué aux paquets, jetons, conteneurs, bref tout SAUF l’intention de vos collègues. Réseaux parano: humains optimistes.

Ensemble, ça donne un modèle de capacités qui se branche sur Scrum, Kanban, GitOps, SAFe, peu importe le beat que votre organisation suit, sans exiger une nouvelle religion.


Les quatre principes (gentiment) irrévérencieux

  1. Tout ce qui bouge est journalisé, scanné ou sinon gueulé. Commits, conteneurs, changements IAM, on s’en fiche de qui a appuyé sur Enter.
  2. Les garde-fous valent mieux que les gates (non, pas celles de Bill !). Une image de base endurcie évite bien des « oups »; un gros bouton rouge « ÉCHEC » un vendredi 16 h, ça fait grincer des dents.
  3. Zero-Trust du système, confiance totale envers les humains (au boulot). On fait tourner les jetons aux heures, mais on fait tourner le blâme hors du post-mortem.
  4. La visibilité = l’amour (gardez quand même vos vêtements). Si un risque peut se cacher, un succès aussi. Les tableaux de bord montrent le flux et les lacunes côte à côte. Les équipes avec une vraie sécurité psychologique et de bons métriques DORA surclassent leurs pairs.

Ça remplace DevOps ?

Ben non, c’est DevOps PLUS.
Imaginez DevOps comme un téléphone intelligent ; SecDevOps est l’étui blindé extra-robuste. Vos apps préférées tournent toujours, mais l’appareil survit aux chutes, aux cafés renversés et au hacker occasionnel.

Constat terrainQuoi faire
Vous avez déjà un CI/CDGreffez les contrôles de sécurité dans les mêmes étapes. Gardez la culture du "green bar", ajoutez juste une touche de violet pour les passes à la sécurité.
Les Ops craignent la surchargeAutomatisez d’abord, annoncez ensuite. Si le scanner réussit en silence 99 % du temps, personne ne crie.
La Sécurité redoute le « Far West »Offrez-leur des tableaux de bord en lecture seule et un droit de veto sur les exceptions, les changements non-documentés, pas sur chaque déploiement.

Zero-Trust sans casser l’ambiance

Pilier Zero-Trust Traduction « humaine-friendly » Garde-fou pas gossant
Vérifier explicitement « On te fait confiance… mais on double-vérifie le système. » Toutes les requêtes API se ré-authentifient en douce; les échecs s’affichent à côté du compte de tests unitaires.
Moindre privilège « Un plus petit rayon d’explosion = moins d’appels à 3 h du mat. » Rôles « PIM » de 2 heures; l’audit se publie dans #sec-télémétrie.
Présumer l’intrusion « Curiosité plutôt que blâme. » Jeux de guerre trimestriels : fuite de faux secrets, beignes pour les gagnants, pas de recherches de coupables.

Starter kit (sprint d’une journée: avec zéro échantillon de code, promis !)

  1. Activez les scanners intégrés. GitHub Advanced Security, SAST GitLab, analyseurs Azure DevOps, SonarQube… prenez ce que votre dépôt offre déjà gratuitement.
  2. Montez un « Risk Radiator ». Un panneau Grafana interne qui fusionne déploiements, vulnérabilités et incidents en une vue bien bruyante et fière.
  3. Activez les rôles Just-In-Time. Utilisez la fonction JIT/PIM de votre cloud pour que n’importe quel·le coéquipier·ère obtienne un accès temporaire sans passer par le service desk.
  4. Planifiez une journée Purple-Team.* Un après-midi, simulez une fuite de jeton et exercez-vous à la trouver et à la corriger ensemble. Top-là: obligatoire.
*Bleu + Rouge = Purple (Violette) au cas ou c'est pas clair...

Métriques qui comptent (et qui gardent tout le monde honnête)

FluxSécuritéCulture
Gestion du changementMTTR-V (correction des vulns)Nb d’humains uniques ayant fermé un billet sécurité
Fréquence de déploiement% de sessions privilégiées qui expirent autoNb de « kudos » pour détection de risque précoce
Points d’histoire livrésNouvelles mesures de sécurité mises en placeAmélioration continue documentée

Si un indicateur monte les équipes l’une contre l’autre, digérez le et jetez-le. S’il déclenche la collaboration, gardez-le.


Dernier mot

SecDevOps + Zero-Trust complète DevOps comme la ceinture de sécurité complète la voiture sport : la balade reste délirante, les accidents font moins mal, et personne ne prétend que la ceinture « remplace » le moteur.

Lancez-vous avec un scanner de vulnérabilités, un tableau de métriques et PIMez vous. Laissez les données parler, laissez les humains rire, et observez la vélocité sécuritaire devenir la nouvelle norme.

Allez hop! Ajoutez cette étincelle violette à vos pipelines, votre futur vous vous dira merci.

Vous voulez en parler? Pour en savoir plus? Contactez-nous, dans la section des commentaires ci-dessous.

To SecDevOps or not to. It isn't even a question.

SecDevOps + Zero-Trust: a Cheeky Field Guide for Teams That Already “Do DevOps”...or dont...

TL;DR — We’re not trying to replace DevOps, we’re giving it a shiny exoskeleton that blocks or exposes risk and still lets the people inside, boogie like it's 1999.

 

What is SecDevOps, Really?

  • DevOps: make value flow fast, learn, repeat. really TLDR.

  • SecDevOps: do the same thing but wire risk-sensors into the plumbing so danger lights up before it bites. (Shift left... again)

  • Zero-Trust: “Never trust, always verify”… applied to packets and tokens, code, containers, everything, EXCEPT colleagues’ motives. In other words, paranoid networks, optimistic humans. (NIST, csrc.nist.gov)

Put them together and you get a capability model that snaps onto Scrum, Kanban, GitOps, SAFe, whatever rhythm your org already claps to, without demanding a brand-new religion.


The Four Cheeky Principles

  1. Everything That Moves Is Logged, Scanned, or Yelled At
    Commits, containers, IAM changes, doesn’t matter who hit Enter.

  2. Guardrails Beat Gates (no, no, not Bill!)
    A pre-hardened base image prevents oopsies; a red “BLOCKED” button at 4 p.m. Friday enrages engineers.

  3. Zero-Trust the System, Full-Trust the Humans, at work.
    We rotate tokens every hour but rotate blame out of the post-mortem.

  4. Visibility = Love (Keep your clothes on, though)
    If a risk can hide, so can a win. Dashboards show flow and flaws side-by-side. Elite teams with strong psych-safety and good metrics outperform their peers on every DORA KPI. (InfoQ, Kodus)


Does This Replace DevOps?

Nope, ­it’s DevOps Plus.
Think of DevOps as the smartphone; SecDevOps is the ruggedized case and screen protector. Your favourite apps still run, but the device survives drops, spills, and the occasional hacker.

Reality Check What to Do
You already have CI/CD Bolt security checks into the same pipeline stages. Keep the green bar culture, just add a “purple sparkle” for security passes. (explanation forthcoming)
Ops teams worry about extra toil Automate first, announce second. If the scanner’s silent-success rate is 99 %, nobody screams.
Security fears a “Wild West” Give them read-only dashboards and veto power on exceptions and undocumented changes, not on every deploy.

How Zero-Trust Fits Without Killing the Vibe

Zero-Trust Pillar Human-Friendly Translation Non-Annoying Guardrail
Verify Explicitly “We trust you, we double-check the system.” All API calls re-auth transparently; failure shows up next to the unit-test count.
Least Privilege “Smaller blast-radius = fewer 3 a.m. calls.” 2-hour click-to-elevate roles; audit trail posts to #sec-telemetry.
Assume Breach “Curiosity over blame.” Quarterly game-days inject fake secrets; winners get doughnuts, not finger-pointing.


Starter Kit (One-Day Sprint, No Code Samples: Promise!)

  1. Turn On Built-In Scanners
    GitHub Advanced Security, GitLab SAST, Azure DevOps Analyzers, SonarQube, or whatever your repo already gives you for free.

  2. Spin Up a “Risk Radiator”
    Internal Grafana panel that glues deployment, vulnerability, and incident metrics into one loud, proud place. Keep granular data about projects for diagnostics, but display the aggregate.

  3. Enable Just-In-Time Roles
    Use your cloud’s JIT/“break-glass”/PIM feature so any teammate can get short-lived access without service-desk limbo.

  4. Schedule a Purple-Team* Game-Day
    One afternoon, fake a token leak and practise finding & fixing it together. High-fives mandatory.

*Red+Blue = Purple, in case you needed the explanation

Metrics That Matter (and Keep Everyone Honest)

Flow Safety Culture
Lead Time for Change MTTR-V (vuln fix) # of unique humans who closed a security ticket
Deployment Frequency % privileged sessions auto-expire # shout-outs for spotting a risk early
Story points delivered New safety measures put into place continuous improvement

If a stat can pit teams against each other, digest it and dump it. If it sparks joint problem-solving, keep it.


Final Nudge

SecDevOps + Zero-Trust complements DevOps the way seatbelts complement sports cars: the ride stays thrilling, the crashes hurt less, and nobody argues that belts “replace” engines.

Start with one scanner, one metric board, and one JIT role.
Let the data speak, let the humans laugh, and watch safe velocity become the new normal.

Now go forth and add that purple sparkle to your pipelines: your future self already thanks you.

Want to talk about it? To know more? Hit us up, in the comment section below.

Saturday, June 10, 2017

About JP

Jean-Paul Lizotte (« Jaypee »)

SecDevOps Transformation Leader | Zero-Trust & Compliance Automation | 30 + years in IT driving resilient, people-centric delivery

I build high-trust, Zero-Trust engineering cultures. From programming Microsoft BASIC in 1981 to leading SOC 2 Type II attestations, my career arcs around one idea: technology should empower people, not become their bottleneck

Today I coach organisations out of “guru dependency” and into collaborative, self-healing SecDevOps ecosystems that cut lead-time, raise security posture, and make audits almost invisible to engineers.

Signature Results

  • SOC 2 Type II readiness in under 12 months – Automation and coordination of implementation of Audit controls.
  • 45 % fewer production defects after embedding SAST / DAST / IaC gates into CI / CD.
  • Daily releases down from bi-weekly by coaching five cross-functional squads on trunk-based development and feature flags.
  • Hub-and-spoke Azure landing zone Bicep Deployment, with policy-as-code and private endpoints, now hosting 30 + workloads.

Playbook

  1. Strategy & Governance – Map business risk to guard-rails; bake compliance into workflow.
  2. Automation – Everything-as-Code: pipelines, policies, infrastructure.
  3. Culture – Psychological safety, shared ownership, continuous feedback loops, security baked-in everything.

Core Competencies

  • SecDevOps Leadership & Cultural Transformation
  • Zero-Trust Architecture & SOC 2 Type II Compliance
  • CI / CD & IaC: Azure DevOps · GitHub Actions · Bicep · Docker / AKS, SonaQube, Snyk
  • Multi-Cloud & Hybrid Governance (Azure-first, some AWS)
  • Data & Pipeline Security: SAST · DAST · Secrets Management · SIEM log centralisation
  • Coaching & Mentoring cross-functional squads

Recent Roles

Emyode | Certified B Corp 

7 years 10 months 

SecDevOps Practice Leader | Deputy CIOSO 

May 2024 - May 2025 (1 year 1 month) 
Montreal, Quebec, Canada 

As Deputy to the CIOSO, I contributed to the company’s operational security strategy by identifying systemic risks, establishing process controls, and implementing scalable governance frameworks across development teams. A key part of this role involved leading the implementation of Emyode’s SOC 2 security readiness program, aligning teams and operations with rigorous audit controls and evidence-based compliance standards. As SecDevOps Practice Leader, I fostered a security-first culture by embedding security at every stage of the SDLC. I coached cross-functional teams on secure automation, threat modeling, and continuous improvement— transforming DevOps maturity into measurable business value. Key Contributions: Operationalized the SOC 2 readiness initiative, from gap analysis to policy implementation and evidence collection, ensuring audit readiness.
  • Designed DevSecOps pipelines with embedded quality and compliance checks. 
  • Led security training, risk workshops, and architecture reviews with both internal teams and external clients. 
  • Established metrics and dashboards for real-time security KPIs and remediation tracking. 
  • Acted as an executive liaison to support communication between stakeholders and security teams. Drove enterprise SOC 2 program, instituted Zero-Trust controls, and centralised observability

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...