Skip to main content

Real incidents + complete FAQ

Summary: four incidents shaped modern DevSecOps — Equifax imposed patch management, SolarWinds revealed the fragility of the build chain, Log4Shell demonstrated that no one knows what they use, and the xz backdoor showed that a patient attacker can become the maintainer of a critical project. This lesson analyzes them, then answers the 14 most frequently asked questions.

1. Equifax (2017) — the textbook case of the unapplied patch​

What makes this case so instructive is its banality. There was no unknown vulnerability, no sophisticated attack technique, no computer genius. A public flaw, a fix available for two months, and a process that didn't work.

The question to ask yourself: how long does your organization take to apply a critical patch? If you don't know the answer, it is probably longer than you think.

2. SolarWinds (2020) — the compromised build chain​

What this incident fundamentally changed: until then, an update signed by a recognized vendor was considered trustworthy. SolarWinds demonstrated that a signature only guarantees the origin, not the integrity of the process that produced the artifact. That is precisely the problem the SLSA framework seeks to solve, by providing guarantees on the build itself.

3. Log4Shell (2021) — no one knows what they use​

Lesson 3 is the one you don't expect in a security course, and it is essential. During Log4Shell, the speed of remediation depended directly on the maturity of the delivery chain. Teams able to deploy in twenty minutes fixed it the same day. Those that needed three weeks for a production release stayed exposed for three weeks.

A good CI/CD pipeline is a security capability, not just a productivity tool. That is the direct link between our CI/CD course and this one.

4. The xz backdoor (2024) — the patient attacker​

This incident is the most troubling of the four, for two reasons. First, it was discovered by chance — thanks to a difference of a few hundredths of a second that a curious engineer decided to investigate. Second, it shows that an attack can target human trust rather than a technical weakness, and unfold patiently over two years.

Lesson 4 goes beyond the technical. A significant part of the world's software infrastructure rests on projects maintained voluntarily by one or two people. Funding these maintainers has become a collective security issue, not a question of generosity.

5. The 14 most frequently asked questions​

1. Where do I start if I have nothing at all?

In this precise order, from most to least cost-effective:

  1. Secrets detection with a local pre-commit hook. Fifteen minutes. Prevents the most mundane leak.
  2. Vulnerable dependency detection (Dependabot, Renovate or equivalent). Fifteen minutes. Covers attack vector number one.
  3. Version the lockfile and use the strict command in CI.
  4. Check your container images: non-root user, minimal base image.
  5. Infrastructure as code analysis if you use Terraform or Kubernetes.
  6. SAST last — it's the noisiest, save it for when the rest is in place.

Don't start by buying a platform. Start with points 1 and 2, today.

2. How long do I have to apply a critical patch?

The deadlines commonly adopted in company policies:

  • Critical and actively exploited (present in the CISA KEV list): 24 to 48 hours.
  • Critical: 7 days.
  • High: 30 days.
  • Medium: 90 days.
  • Low: at the next maintenance cycle.

The important point is not the exact number, it is having one and measuring it. Equifax had no tracked deadline. If you don't know how long you take, the answer is probably too long.

3. How do I convince my management to invest in security?

Don't talk about vulnerabilities, talk about business risk:

  • The cost of a breach: regulatory sanctions (up to 4% of revenue under GDPR), notification, crisis communication.
  • The lost deals: every security questionnaire in a call for tenders asks whether you have suffered an incident.
  • The comparative cost: automatic vulnerable dependency detection is free or nearly free.

The most effective argument: present the Equifax case. A known flaw, a fix available for two months, and hundreds of millions of dollars in consequences. Then ask: "how long do we take, ourselves?".

4. Will security slow down my deliveries?

Done badly, yes. Done well, no — and it can even speed them up.

What slows things down: a three-week manual audit, and a tool that raises 4,000 alerts.

What doesn't slow things down: a thirty-second analysis in the pipeline that blocks only on critical and exploitable.

What speeds things up: studies on DevOps practices regularly show that the highest-performing teams in delivery are also the highest-performing in security. The reason is simple: automating checks removes the manual approvals that used to block everything.

5. I pushed an API key into Git. What should I do?

In this order, immediately:

  1. Revoke the key with the provider. This is the essential step, everything else is secondary.
  2. Generate a new key and place it in a secrets manager, not in the code.
  3. Check the provider's access logs to detect suspicious usage.
  4. Clean the history if you wish, but never considering that it replaces revocation.
  5. Install a local secrets detection hook to prevent a recurrence.

Don't waste time cleaning the history before revoking. On a public repository, every minute counts.

6. Should we do penetration testing?

Yes, but not first. A penetration test costs several thousand euros and takes one to two weeks. Doing it before putting the basics in place amounts to paying dearly to learn that you have vulnerable dependencies — something a free tool would have told you in fifteen minutes.

The right moment: when your automatic controls are in place and clean. The penetration test then finds what automation cannot see — business logic flaws, exploitation chains, design defects.

Worth knowing: a penetration test often becomes a contractual requirement as soon as you sell to large companies or the public sector.

7. How do I secure a Kubernetes cluster?

The essential points, in order of importance:

  • Restrictive RBAC — no cluster admin role granted broadly.
  • Pod security context — non-root user, read-only filesystem, no privilege escalation.
  • Network policies — by default, in Kubernetes, all pods can talk to each other. That is almost always undesirable.
  • Secrets — Kubernetes secrets are not encrypted by default, only encoded. Enable encryption at rest or use an external vault.
  • Admission controller — refuse unsigned images or non-compliant configurations.
  • Namespace isolation with resource quotas.

The point about network policies surprises a lot of people: Kubernetes is open by default. See our Kubernetes course.

8. Is AI-generated code a security risk?

It is a real and recent topic. Three points to consider:

  • The models were trained on public code, including vulnerable code. They therefore sometimes reproduce dangerous patterns, notably SQL queries built by concatenation.
  • Generated code looks correct, which lowers vigilance during review. Code that seems clean gets reviewed less than obviously shaky code.
  • Models can suggest non-existent dependencies, which attackers then publish under that exact name — a variant of typosquatting.

The good practice: treat generated code exactly like the code of a competent but inexperienced intern. Review it, and let your automatic analyses do their work on it.

9. What's the difference between a vulnerability, an exploit and a threat?
  • Vulnerability — a weakness in a system. Example: an SQL query built by concatenation.
  • Exploit — the concrete technical means of using that weakness. Example: the precise character string that triggers the injection.
  • Threat — the actor likely to act. Example: a criminal group automating exploitation.
  • Risk — the combination of the three, weighted by impact. It is the only one that matters for prioritizing.

The practical use: a vulnerability with no available exploit and no exposure represents a low risk. A less severe vulnerability that is actively exploited on a public service represents a high risk.

10. What is a threat model, and how do I make one?

It is a structured thinking exercise, of two hours, at the start of a project. Four questions are enough:

  1. What are we building? A simple diagram of the components and data flows.
  2. What can go wrong? The STRIDE method helps: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.
  3. What are we doing about it? The measures for the risks retained.
  4. Did we do a good job? A review after implementation.

It is the most cost-effective security activity there is, because it happens before a single line of code is written. It requires no tool.

11. What jobs and salaries in security?

The main jobs:

  • DevSecOps engineer — automates security in pipelines.
  • Application security engineer — specialized in code and application security.
  • Penetration tester (pentester) — actively hunts for flaws.
  • Security operations center analyst — detects and responds to incidents.
  • Security architect — designs security models upstream.

Orders of magnitude in France, highly variable by region and sector:

  • Junior: between 35,000 and 45,000 euros gross per year.
  • Mid-level (3 to 5 years): between 50,000 and 70,000 euros.
  • Senior or specialized: above 75,000 euros, notably in the Paris region, in consulting and in finance.

The field is structurally short of candidates, which works in favor of those who train up.

12. Do I need a security certification?

Useful, but after hands-on experience. The most recognized:

  • CompTIA Security+ — a good generalist entry point.
  • CEH — penetration testing oriented, very visible in recruitment.
  • OSCP — demanding and highly respected for penetration testing, purely practical.
  • CISSP — management oriented, requires five years of experience.
  • Cloud provider security certifications (AWS, Azure, Google) — in very high demand at the moment.

The realistic advice: a demonstrable personal project — a pipeline with automatic analyses, cleanly managed secrets, hardened images — often convinces more than a certification in a technical interview.

13. How do I learn offensive security legally?

Never test a system you don't own without written authorization. It is a criminal offense, even without intent to harm, even without damage caused.

The legal learning platforms designed for this:

  • TryHackMe — very progressive, ideal for beginners.
  • Hack The Box — more demanding, challenge oriented.
  • PortSwigger Web Security Academy — free, excellent, web specialized.
  • OWASP Juice Shop — a deliberately vulnerable application to install at home.
  • Bug bounty programs — an explicit legal framework, with a defined scope.

Understanding attack makes you much better at defense, provided you do it within a legal framework.

14. Where do I start concretely tomorrow morning?

Five-day plan, applicable to a real project:

  1. Day 1 — Install a local secrets detection hook on your main repository. Then analyze the full history once. You will probably find something.
  2. Day 2 — Enable automatic vulnerable dependency detection. Look at the report, fix the critical ones.
  3. Day 3 — Check your container images: non-root user, minimal base image, no secret in the layers.
  4. Day 4 — Add an SCA analysis to your pipeline, in report-only mode to start.
  5. Day 5 — Do a two-hour threat model on your most sensitive feature.

The following week: make blocking what is clean, and generate an SBOM on every build.

The principle: each day brings a real benefit. Don't plan six months of work.

6. What you have learned in this course​

7. Your next step​

Track 1 · Complete your technical culture​

Track 2 · Move on to practice​

Track 3 · Train legally​

  • PortSwigger Web Security Academy — free and excellent
  • OWASP Juice Shop — a deliberately vulnerable application
  • TryHackMe — a progressive path for beginners

8. One last piece of advice​

Do the simplest thing, today.

Don't wait for a security budget, or for an expert on the team. Install, this week, pre-commit secrets detection and vulnerable dependency detection. Thirty minutes of work in total, free.

These two measures cover the two most frequent causes of incidents in the trade: the leaked secret and the unpatched library. That is the majority of the real risk, for almost nothing.

The rest — SBOMs, signatures, threat models, penetration tests — will come later, one brick at a time.

Remember in 30 seconds​

  • Equifax: known flaw, fix available for two months, 140 million people affected. A process problem.
  • SolarWinds: the build chain compromised. The source code was clean, the binary trapped. A signature guarantees the origin, not the integrity of the process.
  • Log4Shell: CVSS score of 10.0. Organizations with an SBOM answered in minutes, the others in weeks.
  • A good CI/CD pipeline is a security capability — during Log4Shell, the speed of remediation depended on delivery maturity.
  • xz backdoor: two years of patience, discovered by chance. Human trust is an attack vector.
  • Funding the maintainers of critical components is a collective security issue.
  • Secret pushed into Git: revoke first, clean up afterwards. Don't waste time.
  • AI-generated code reproduces vulnerable patterns and looks correct — so it gets reviewed less.
  • The threat model is the most cost-effective security activity: two hours, no tool.
  • Never test a system you don't own without written authorization.
  • Start with two things: secrets detection and vulnerable dependency detection. Thirty minutes, free, covers the majority of the real risk.

Thank you for taking this DevSecOps discovery course! 🎉

Want to continue? Back to the table of contents or move on to the Premium Security DevOps course.

Last step: take the end-of-course quiz — five corrected and explained questions, three minutes, to check that the essentials have been acquired.