Friday morning, 9:30. A message from the security team: "A critical CVE hits one of our dependencies. What's the plan?" You search, browse various sites, while a colleague had seen the information two days earlier in their personal watch, without passing it on. Result: two days late on a potentially critical incident.
The DevSecOps ecosystem moves fast. The OWASP Top 10:2025, announced in November 2025 and published in its final version in January 2026, is the first revision since 2021 and adds software supply chain failures. The DORA model went from four to five metrics in 2024, then its 2025 report was renamed State of AI-assisted Software Development. A team still steering by the 2021 references works with an outdated compass.
Technology watch is a professional skill in its own right, just like writing a pipeline or diagnosing an incident. This lesson is for DevOps and DevSecOps engineers who endure their watch more than they drive it. It proposes a system that captures, filters and turns into action useful information, with a part dedicated to security watch, the one that tolerates no delay.
What you will learn
- Structure a sustainable technology watch, without sacrificing your evenings or your attention.
- Follow the official security alert sources (CERT-FR, the CISA KEV catalogue, GitHub advisories, OSV, EPSS) and prioritise with them.
- Identify reliable sources (software forges, RSS feeds, newsletters, communities) suited to your context.
- Build a complete workflow: collect, filter, set aside, act.
- Anchor realistic daily, weekly and monthly routines.
- Recognise common traps (FOMO, squirrel syndrome, passive watch) to avoid them.
Why is technology watch so often lacking?
Before proposing solutions, you need to understand why watch is so often neglected or poorly practised. This diagnosis identifies the obstacles to overcome and shapes the system to build.
The symptoms of a missing or dysfunctional watch
In many organisations, watch suffers from several interconnected ills. Recognising them is the first step, and each calls for a different answer in the workflow described in this lesson.
Purely reactive learning: the team only discovers a technology, a practice or a vulnerability when a problem occurs. You learn about a critical CVE (Common Vulnerabilities and Exposures, the standard public identifier of a known vulnerability) the day it hits production. This constant reactivity breeds stress and rushed decisions.
Information silos: everyone has their own sources and discoveries, but no mechanism shares them. One colleague follows Kubernetes closely, another cloud security, and their knowledge stays siloed: on a cross-cutting topic, nobody has the full picture.
Paralysing overload: faced with the daily flood of publications, many give up on any organised watch. Tabs pile up, articles "to read someday" stack up, and guilt grows without any action coming out of it.
No turning into action: even when collected, information is rarely used. You make a mental note to try a tool "when there's time", then forget it. Watch becomes passive consumption instead of a lever for continuous improvement.
Permanent FOMO: the Fear Of Missing Out pushes people to follow and read everything. This non-selective approach is exhausting and dilutes attention on topics unrelated to your real context.
The consequences for the organisation
These individual dysfunctions have collective repercussions. The table links each consequence to its concrete impact and its hidden cost, often invisible until an incident reveals it.
| Consequence | Concrete impact | Hidden cost |
|---|---|---|
| Late on vulnerabilities | Longer fix delay, wider exposure window | Risk of compromise, possible regulatory sanctions |
| Accelerated technology debt | Obsolete tools, outdated practices | Costly maintenance, hard recruiting |
| Missed opportunities | Useful tools ignored | Sub-optimal productivity, frustration |
| Ill-informed decisions | Choices based on incomplete information | Regretted investments, painful migrations |
| Demotivated talent | Feeling of stagnation | Departures, hard to retain |
How do you organise a security watch?
Security watch is the part of watch that tolerates no delay: an exploited vulnerability can reach your production within hours. It relies on official sources, structured and machine-readable, rather than on the luck of a news feed.
The official alert sources
These sources publish verified data, often in a machine-readable format (RSS feeds, JSON, API). You plug them into your watch collector, and some directly into the team's analysis tools.
| Source | What it publishes | How to follow it |
|---|---|---|
| CERT-FR (ANSSI) | Security alerts and advisories in French, per product | RSS feed of cert.ssi.gouv.fr |
| CISA KEV | Catalogue of vulnerabilities whose exploitation is confirmed | Online catalogue and JSON feed |
| GitHub Advisory Database | Security advisories per ecosystem (npm, PyPI, Go, Maven...) | Dependabot alerts on your repositories |
| OSV | Aggregated database of open source vulnerabilities, per package and version | osv.dev, the osv-scanner tool |
| EPSS (FIRST) | Probability that a CVE is exploited in the next 30 days | Score shown by recent scanners (Grype, Trivy) |
| Distribution trackers | Fix status per system package (Debian, Red Hat, Ubuntu) | Security tracking pages of each distribution |
| Vendor advisories | Bulletins for the products you run | Each vendor's feeds or mailing lists |
For your repositories' dependencies, the most reliable watch is automatic: a tool such as Dependabot, Renovate or osv-scanner compares your lock files with advisory databases and opens an alert or a merge request. Human watch then covers what these tools cannot see: infrastructure components, appliances, managed services.
Prioritising a security alert
A security alert is triaged on three signals, from the most urgent to the most contextual. The diagram shows how they lead either to an immediate fix or to the register of debt, never to oblivion.
- Is exploitation confirmed? A CVE listed in the KEV catalogue is already exploited by attackers: it is the strongest signal.
- What is the probability of exploitation? The EPSS score estimates it over the next 30 days; it complements the CVSS score, which measures theoretical severity, not the real threat.
- Are you exposed? A vulnerable component that is not used, or only reachable internally, does not have the same urgency as an Internet-facing service.
An exploited or likely flaw on an exposed service is fixed right away; the rest goes to the register, with an owner and due date, following the rule from the security debt lesson. Vulnerability management then details triage and fixing.
Which technology watch sources should you follow?
Beyond security alerts, an effective watch relies on a mix of sources suited to your context. Each type of source has its strengths and limits; the goal is not to consume everything, but to choose and orchestrate. The diagram groups them by role.
Software forges: GitHub and GitLab
Software forges are often under-used watch sources: a real-time observatory of how tools evolve, including for software supply chain security. A release that quietly fixes a flaw in a transitive dependency does not always get a CVE the same day.
Releases and changelogs: following the releases of the projects you use lets you anticipate changes and be alerted quickly to security fixes. On GitHub, the "Watch" menu offers a custom subscription limited to releases, without the noise of issues and pull requests.
Trending projects: GitHub's "Trending" section highlights projects gaining popularity, a good indicator of emerging tools. Filter by language or period to target your topics.
Stars as a social signal: a project's number of stars is an imperfect but useful indicator of its adoption. A project gaining them fast is worth a look, without being a quality guarantee.
Discussions and issues: issues reveal common problems, advanced uses and upcoming changes. Those labelled "discussion" or "enhancement" give a view of future directions.
Aggregators: RSS and custom feeds
RSS feeds (Really Simple Syndication, an open format that pushes a site's new content) remain one of the most powerful watch tools. Unlike social networks, where an algorithm decides what you see, RSS gives you full control over your sources.
Why RSS is still relevant: despite Google Reader closing in 2013, RSS never disappeared. Most technical blogs and news sites, including CERT-FR, still publish a feed. It is an open format that respects your attention, with no intrusive advertising or imposed recommendation.
Aggregators centralise and organise your feeds. Feedly is the most widespread, with a free tier enough to start; Inoreader adds advanced filtering rules; Miniflux and FreshRSS are open source solutions to self-host, to keep control of your data.
Daily.dev is a browser extension that aggregates popular technical articles in your new tab. Useful to discover unknown sources, it carries a real risk of procrastination: keep it for watch time.
Newsletters: human curation
Newsletters benefit from human curation: someone has read, filtered and selected the content for you. This work gives newsletters an excellent ratio between quality and time invested, as long as you follow few of them.
- General DevOps and cloud: TLDR (very condensed daily digest), DevOps Weekly (Gareth Rushgrove's weekly review, published since November 2010), SRE Weekly (reliability and observability), The New Stack (cloud-native technologies).
- Security: tl;dr sec (application and cloud security, weekly), Hackaday's This Week in Security column, the Risky Business newsletter.
- French-speaking: Programmez! (development and DevOps), Human Coders News (community aggregator).
Social networks: signal and noise
Social networks can be excellent watch sources or formidable attention traps. It all depends on how you use them: thematic lists rather than a chaotic main feed.
X (formerly Twitter) is still a place where many professionals share their findings; the key is to create lists ("security researchers", "Kubernetes", "DevOps") that each become a targeted feed. Mastodon gathers an active tech community, notably on specialised instances such as infosec.exchange, with no recommendation algorithm.
LinkedIn is mostly useful to follow vendor announcements and field reports, at the cost of considerable noise. Reddit, with r/devops, r/kubernetes, r/netsec or r/sysadmin, offers real field reports, sorted by member votes.
French-speaking communities
French-speaking sources bring their own value: field reports in a similar regulatory context (GDPR, ANSSI), local events and a professional network.
The Journal du Hacker, a French-speaking equivalent of Hacker News, surfaces French technical articles by vote. Human Coders offers an article aggregator and a newsletter. Many French-speaking Discord servers and Slack spaces also allow quick questions and answers between practitioners.
Conferences and events
Conferences are moments of intensive watch: in a few days, you see trends, field reports and vendor announcements. Most publish their talks for free as videos, so you can benefit without attending.
- International: KubeCon + CloudNativeCon, the event of the cloud-native ecosystem; DevSecCon, dedicated to DevSecOps; HashiConf, for the HashiCorp ecosystem.
- French-speaking: Devoxx France, the largest developer conference in France; DevOps D-Day; and local Docker, Kubernetes or DevOps meetups.
Podcasts and video channels
Audio and video formats allow watch during commutes or sport, and suit topics that need detailed explanations.
- DevOps and cloud: Arrested DevOps (DevOps culture and practices), the Kubernetes Podcast from Google, The Changelog (open source maintainers).
- Security: Risky Business, Darknet Diaries (hacking stories), NoLimitSecu (French-speaking security podcast).
- Video: the channels of the CNCF (Cloud Native Computing Foundation, the foundation that hosts Kubernetes) publish conference talks and webinars.
How do you go from collection to action?
Having access to many sources is not enough: the challenge is to turn this raw flow into actions. The watch workflow takes information through four phases, and relies on habits and automation rather than sheer willpower.
Phase 1: collect in few entry points
The first phase gathers all your sources in a limited number of entry points. The classic mistake is to visit every site, every network, every newsletter: attention fragments and time flies. Aim for two or three entry points at most.
An aggregator such as Feedly or Inoreader becomes the central point for regular feeds, organised by category:
Category "High priority" - Releases of critical projects (Kubernetes, Terraform...) - Security feeds: CERT-FR, advisories of the vendors you useCategory "General DevOps" - The New Stack, blogs of recognised expertsCategory "Cloud providers" - What's new pages of your providersCategory "French-speaking community" - Journal du Hacker, French technical blogsCategory "To sort" - New feeds on trialAfter a few weeks, a "to sort" feed joins a category or disappears if its signal-to-noise ratio is too low.
A dedicated email address for newsletters separates watch from work mail: the main inbox stays clean, and you read newsletters in watch mode, not in the middle of an urgent task. Filtering rules sort mail by rhythm (daily, weekly, monthly).
Check this inbox once a day for dailies and once a week for weeklies, no more.
Critical topics deserve alerts pushed to you:
- Dependabot alerts or Renovate merge requests for your repositories' dependencies;
- a subscription to the releases of critical projects on GitHub;
- a feed (RSS to Slack or Teams, through n8n or a bot) pushing CERT-FR advisories for the products you run to a team channel.
Too many alerts kill the alert: keep this channel for information that needs quick action.
Phase 2: filter signal from noise
Once sources are centralised, filtering decides the effectiveness of the whole watch. Without it, you spend hours on worthless content; too aggressive, it misses the essentials. The three-second rule helps: for each title, a single question, "is this relevant to my current context?". Without a clear "yes", move on.
Four criteria guide this triage: relevance to your stack or a current project, timing (is it actionable now?), the source's credibility on the topic, and depth (in-depth piece or yet another shallow tutorial). Read titles and introductions, spot the words that matter ("breaking change", "security", "deprecated").
Phase 3: set aside for a deeper read
Selected articles go into a read-it-later tool, to read during the weekly slot. This market has been shaken up: Omnivore closed in November 2024 after its acquisition by ElevenLabs, and Pocket closed in July 2025. A good illustration of the dependency risk on a proprietary service: choose an open source tool or export your data regularly.
| Tool | Type | Strengths | Limits |
|---|---|---|---|
| Instapaper | Online, free with paid options | Clean interface, good article rendering | Advanced features are paid |
| Wallabag | Self-hosted, free | Open source, full control of data | Needs hosting |
| Raindrop.io | Online, free with paid options | Collections, collaboration | More bookmarks than reading |
| Readwise Reader | Online, subscription | Articles, newsletters, PDFs and RSS in one place | No permanent free tier |
A consistent tagging system (by urgency, domain, action, format) makes rereading easier. And a purge rule avoids the digital dump: an article unread after 30 days is archived. If it was really important, it will come back.
Phase 4: act on the information
Watch only creates value if it leads to an action. An article read without follow-up remains intellectual entertainment. Five types of actions come back, from the lightest to the most committing.
-
Test quickly
Fifteen minutes in a sandbox are often enough to judge a tool. A throwaway container avoids polluting your workstation, with an image pinned by digest:
Terminal window mkdir -p ~/lab/"$(date +%Y-%m-%d)"-new-tool && cd "$_"docker run -it --rm alpine:3.22@sha256:5291449c3df73caf6ed85e649dec1b9e818b39a5d8c871e97afc13e9cd5e8fa8 /bin/sh -
Document for yourself
A dated Markdown note (topic, key points, relevance for your context, next actions) becomes a valuable personal knowledge base.
-
Share with the team
A watch channel, a fifteen-minute slot in the weekly meeting for discoveries, a shared space for lasting resources.
-
Propose a change
A significant discovery is formalised: problem addressed, proposed solution, estimated effort, who does what and when.
-
Create content
Rephrasing for others, in an article or an internal presentation, is the best way to anchor what you learned.
Which watch routines should you adopt?
An effective watch relies on regular routines rather than marathon sessions. As with sport, regularity matters more than intensity: a few minutes a day beat several hours once a month.
The daily routine (10 to 15 minutes)
Put these minutes at a fixed moment: with the morning coffee, at lunch break or before shutting down. You scan the titles of the aggregator, skim newsletters, set aside what deserves a deeper read, and look at the day's security alerts. You do not read full articles, test anything or follow tutorials.
The weekly routine (30 to 60 minutes)
Once a week, a longer slot is used to read two or three articles set aside in depth, test a tool, take notes and prepare a share for the team. You also clean the reading list, and reread the debt register for entries coming from the security watch.
The monthly routine (2 to 3 hours)
Once a month, take a step back on the system itself. Which sources brought the most value? Which are never read? Did the watch lead to actions? Have your priorities changed? You unsubscribe from low-value sources, add one or two recommended by peers, and update alerts.
How do you know your watch works?
Without clear criteria, you fall into one of two extremes: giving up for lack of visible results, or persisting with an ineffective system for fear of missing something. A few signals, positive and negative, settle the question.
A working watch produces observable results: at least one useful discovery and one concrete action a month, no major surprise about your stack, colleagues asking you what you have seen, controlled time, a reading list that stays under twenty to thirty articles.
Conversely, some warning signs call for an adjustment: a watch that stresses more than it informs, hundreds of unread articles, no useful discovery in memory, regular surprises about what colleagues already know, more than thirty minutes a day with no tangible result. If nothing improves after two or three months of regular practice, change approach rather than persisting.
Two concrete scenarios
These two scenarios are deliberately generic: they show the reasoning, not a real vulnerability or tool. The first illustrates security watch, the second technology watch serving an improvement.
Scenario 1: detecting a critical CVE early
You run a Kubernetes cluster in production. Your watch includes the CERT-FR feed, the subscription to Kubernetes releases and the Dependabot alerts of the team's repositories. On Monday morning, the daily routine surfaces an advisory: a privilege escalation in a cluster component, fixed in the maintenance versions of each branch.
In five minutes, you check whether you are affected by comparing the cluster version with the affected versions in the advisory:
kubectl versionkubectl get nodes -o wideYour version is among the affected ones: the component is in use.
You apply the three signals: is the CVE in the KEV catalogue? What is its EPSS score? Is the service exposed? Here, no known exploitation but a cluster reachable from the Internet: the fix is planned within a few days and the entry is recorded in the register, with an owner and a due date. A message to the team sums up the risk and the proposed action.
The new version is tested in staging, validated, then deployed during a maintenance window. The register entry is closed with the deployment reference. Without watch, the discovery could have taken weeks.
Scenario 2: discovering a CI/CD optimisation
Your pipelines are getting longer and the team complains, but nobody has time to dig in. During the weekly routine, an article spotted in a newsletter presents three techniques for GitLab CI: parallelisation with parallel: matrix, a dependency cache keyed on the lock file, and a pre-built build image.
You take notes: your cache is badly configured (a half-hour fix, a quick win), parallelisation takes a few hours, the pre-built image a day. You share a structured message in the team channel: finding, quick win, broader overhaul, link to the notes, a proposal to discuss it in retrospective.
The quick win is applied within the week, the overhaul is planned for the next quarter. The team recovers cumulative waiting time, and the value of watch is shown by a measurable result.
Which traps should you avoid?
Watch has classic traps that experienced practitioners fall into too. The table pairs them with their symptoms and a simple solution.
| Trap | Symptoms | Solution |
|---|---|---|
| Source perfectionism | Hours configuring the "perfect" aggregator instead of watching | Start with 5 to 10 sources, adjust gradually |
| Squirrel syndrome | Hundreds of articles set aside, never read | Archive any article unread after two weeks |
| Paralysing FOMO | Wanting to follow everything, everywhere | Three to five priority topics, the rest deliberately ignored |
| Passive watch | Lots of reading, no action | At least one action a week coming from the watch |
| Novelty effect | Rushing to every trendy tool | Let it settle for a few months before investing time |
| Isolation | Watching alone, without sharing | A channel and a weekly sharing slot |
| Alert without follow-up | A CVE seen, neither fixed nor recorded | Fix it right away or record it in the debt register |
| Confirmation bias | Only following sources that confirm your opinions | Add one or two sources from other communities |
Key points
- Watch is a system, not a one-off activity: ten minutes a day beat eight hours once a quarter.
- Security watch relies on official sources (CERT-FR, KEV, GitHub advisories, OSV, EPSS) and, for dependencies, on automatic tools.
- An alert is triaged on three signals: confirmed exploitation (KEV), probability of exploitation (EPSS), service exposure.
- A seen alert never stays without follow-up: an immediate fix or a debt register entry, with an owner and a due date.
- Fewer sources, better handled: five excellent sources beat fifty mediocre ones, and filtering is a skill.
- No action, no value, and sharing multiplies a discovery's value.
- Tools change, the method stays: Pocket and Omnivore closed, the collect, filter, set aside, act method remains.
Knowledge check
Check that you have the essentials of this guide. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Observability: logs, metrics and traces
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
The questions below cover the most frequent doubts about technology watch: the time to devote to it, the sources to favour and how to make it useful to the team.