Showing posts with label DigitalResilience. Show all posts

Monday, June 9, 2025

Why the “Dev(SEC)Ops Rockstar” Myth Persists

Why the “DevOps Rockstar” Myth Persists

A Badging Bonanza for Ambitious Engineers

Instant credibility. One LinkedIn title change, and you’re the go-to guru for pipeline pain.
Tool-collector’s paradise. Kubernetes today, service mesh tomorrow—learning curves feel like career hacks.
Hero dopamine. Shipping hot-fixes at 2 a.m. earns high-five emojis and a reputation for “getting things done.”

An Irresistible Shortcut for Businesses

One neck to wring. Executives like simple org charts; a single “DevOps Department” feels efficient. (medium.com)
Budget sleight of hand. Blending Dev, Ops, and Sec into a single role avoids hiring three specialists, or so they believe.
Illusion of modernity. Saying “we’ve adopted DevSecOps” looks innovative in board decks: whether or not practices change.

The result? A fragile setup that contradicts DevOps’ founding principles of shared ownership and flow.

The Hidden Costs of the Hero Model

Risk	Why It Hurts	Data Point
Bus Factor = 1	One vacation, resignation or (heaven forbid) illness, stalls releases and repairs.	The bus-factor concept warns that low redundancy is a project-killer. (en.wikipedia.org)
Bottlenecks & Burnout	All changes queue behind a single reviewer/deployer or team.	Elite teams ship 182× more often precisely because work is spread, not centralized. (multitudes.com)
Security Drift	Late “security gates” create surprise blockers.	Fixing a defect in prod costs up to 30× more than in dev. (linkedin.com)
AI Over-hype	Super-charging one person with Gen-AI increases batch size and failure risk.	A 25 % jump in AI use correlates with -1.5 % throughput and -7.2 % stability. (cloud.google.com)

None of this is sustainable; it just hides toil until it explodes.

DevOps & SecDevOps Done Properly

“High-performing teams are cross-functional, platform-enabled, and metrics-driven.”: DORA 2024

Shared Responsibility. Developers own runtime; operators code infrastructure; security writes policies as code.
Platform Engineering. A small team curates paved-roads (templates, golden images, self-service portals).
Shift-Left Security. Static analysis, secret scanning, and policy-as-code fire on every pull request.
Continuous Learning. Blameless post-mortems feed dashboards and backlog grooming.
Data-Driven Improvement. Track Lead-Time, Deployment Frequency, MTTR, and Change-Fail Rate, not vanity stats. Elite performers beat laggards by 1-2 orders of magnitude on all four. (multitudes.com)

Cross-functional teams with these traits are 50 % more likely to succeed. (moldstud.com)

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

Invite security to the daily stand-up. Today. Zero slide decks required.
Automate one pain-point.
Add one security gate: Owasp, SAST, SCA or container scan, before the next sprint review.
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

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:

Invitez la sécurité au stand-up quotidien. Dès aujourd’hui. Pas besoin de diapos.
Automatisez une "épine dans le pied"
Ajoutez un seul contrôle de sécurité: Owasp, SAST, SCA ou scan de conteneur, avant la prochaine revue de sprint.
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

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

Tout ce qui bouge est journalisé, scanné ou sinon gueulé. Commits, conteneurs, changements IAM, on s’en fiche de qui a appuyé sur Enter.
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.
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.
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 terrain	Quoi faire
Vous avez déjà un CI/CD	Greffez 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 surcharge	Automatisez 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 !)

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

Flux	Sécurité	Culture
Gestion du changement	MTTR-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 auto	Nb de « kudos » pour détection de risque précoce
Points d’histoire livrés	Nouvelles mesures de sécurité mises en place	Amé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

Everything That Moves Is Logged, Scanned, or Yelled At
Commits, containers, IAM changes, doesn’t matter who hit Enter.
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.
Zero-Trust the System, Full-Trust the Humans, at work.
We rotate tokens every hour but rotate blame out of the post-mortem.
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!)

Turn On Built-In Scanners
GitHub Advanced Security, GitLab SAST, Azure DevOps Analyzers, SonarQube, or whatever your repo already gives you for free.
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.
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.
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.

Thursday, May 15, 2025

Sustainability Is the New Performance

We talk a lot about performance — in business, in systems, in teams.

How fast?
How scalable?
How productive?

These are important questions, but in this age — where AI consumes ever-growing energy, where our ecological systems are in crisis, and where relentless economic growth strains planetary and human limits — we need to start asking a deeper, more consequential question:

Is it sustainable?

The Illusion of Infinite Growth

For decades, growth has been treated as the gold standard: the only meaningful metric of success.
More users. More compute. More features. More revenue.

But more does not always mean better. And growth at all costs often comes with a hidden price tag: environmental degradation, burnout, inequality, technical debt, and fragility.

In technology, we idolize velocity.
We celebrate disruption.
We chase scale.

But systems that are optimized only for speed are systems that eventually fail, or worse, fail us. They burn resources, burn out people, and leave behind operational chaos.

Sustainability as a First-Class Metric

It’s time we shift the conversation.
Sustainability is not an afterthought.
It’s not a “nice to have.”
It’s a first-class requirement, every bit as essential as uptime, latency, or throughput.

When we ask “Is it sustainable?”, we don’t just mean:

Is it green?
Is it carbon-neutral?
Is it efficient?

We mean:

Can this system adapt to change without collapsing?
Can the people running it thrive, not just survive?
Can we maintain it responsibly, over time, without heroics?
Can it be trusted, observed, explained, and governed?

Designing for Endurance, Not Just Velocity

Sustainable tech leadership means:

Building systems that last: observable, modular, explainable, and respectful of real-world limits.
Automating with intent: using automation to reduce cognitive load, not to mask complexity.
Embedding governance: not because compliance requires it, but because trust is the currency of modern systems.
Caring for our teams: designing processes and expectations that protect mental health and build resilience.

Sustainability isn’t a limit. It’s a lens.

It reveals where we’re going too fast.
Where we’ve skipped the fundamentals.
Where we’re scaling waste instead of value.

What Does Growth Really Mean?

If your infrastructure burns more energy than it returns in value…
If your AI model can’t be explained or constrained…
If your delivery pipeline causes stress, rework, and shadow systems…

Is that really growth?
Or is it just noise at scale? "Oh look at me, I'm a big, something."

We need a new kind of performance metric, one that includes endurance, clarity, and responsibility.

A New Definition of Value

The most valuable systems in the next part of this century won’t just be fast.
They’ll be trusted.
They’ll be sustainable.
They’ll be governed, observable, and humane.

Let’s make sustainability more than a buzzword
Let’s make it a design principle, a business imperative, and a cultural norm.

Because if your system can’t last…
If your growth burns everything behind it…

That’s not forward.
That’s backwards.