Alexandre Dulaunoy - adulau - Home Page

Don’t Do Team Meetings

Mon, 27 Apr 2026 12:02:00 +0200

Don’t Do Team Meetings

Regular team meetings are often treated as a default part of work. They are seen as a sign of coordination, alignment, and healthy communication. In practice, they often reveal the opposite.

A recurring team meeting where everyone goes around the room to explain what they did last week is usually not a good use of time. It turns communication into a performance instead of a real exchange of useful information. If the team needs a formal meeting just to learn what people have been doing, that is often a sign that day-to-day communication is already failing.

The problem with “what did you do last week?” meetings

They happen too late

Work should not become visible only once a week in a meeting. If something matters, it should already have been shared when it happened: when a task was completed, when a blocker appeared, when a useful idea emerged, or when help was needed.

Waiting for a meeting to report progress means information is delayed, and delayed information is usually less useful.

They expose a communication issue

If a team depends on a weekly meeting to know what others are achieving, the issue is not a lack of meetings. The issue is a lack of continuous communication.

People should not discover completed work, current priorities, or open questions only during a scheduled call. A healthy team communicates continuously, in context, and in writing when possible. If this is not happening, adding more meetings does not solve the underlying problem.

They are often boring

Most of these meetings are passive. One person speaks, others wait for their turn, and very little real discussion happens. In many cases, people are not truly listening. They are replying to emails, reading messages, or working on something else while the meeting continues in the background.

That is usually a sign that the meeting is not useful enough to deserve full attention.

They scale badly

The more people you add, the worse the meeting becomes.

Each additional participant increases the duration, reduces relevance, and lowers attention. What may be tolerable with three people becomes a waste of time with ten. A long status meeting with many participants often creates very little value for most of them.

A meeting that costs one hour for ten people is not a one-hour meeting. It is a ten-hour cost for the team.

The alternative is simple: share continuously in chat, in the right place, as the work happens.

This is the model we use in our team.

Instead of relying on status meetings, communication happens across several chat rooms:

one global room for the whole team
one fun room for informal exchanges
multiple project-specific rooms

The rule is simple: use the project room first when something is related to a specific project. This keeps information close to the people who need it, while still making it visible to others who want to follow along.

Everyone can join all rooms. The only mandatory ones are the global room and the fun room.

This model has several advantages:

Communication becomes timely

Updates are shared when they matter, not days later. People can react sooner, help sooner, and stay informed without waiting for a calendar slot.

Communication becomes contextual

Project-related discussions stay in project rooms. Team-wide information goes to the global room. Casual conversation has its own place. This reduces noise and makes it easier to find relevant information later.

Communication becomes inclusive without being interruptive

People can read when they have time. They do not need to stop their work for a meeting that may not concern them. They can stay informed asynchronously and still participate when relevant.

There is no need to force reactions. Sharing is enough.

Communication becomes searchable and durable

A chat message leaves a trace. It can be read later, linked, searched, or revisited. A spoken status update in a meeting often disappears as soon as the call ends.

Meetings should be the exception

This does not mean that all meetings are bad. Some meetings are necessary:

to make a decision that requires live discussion
to resolve a conflict or a misunderstanding quickly
to work through a complex topic together
to handle urgent coordination in real time

But a recurring status meeting is rarely the best tool for those cases.

Conclusion

If your team has a weekly meeting just to explain what everyone did last week, the problem is probably not that you need a better meeting. The problem is that you need better communication during the week.

A team that shares continuously in chat is usually more informed, more efficient, and less dependent on rituals that consume time without creating much value.

Do not default to team meetings.

Communicate continuously. Share in context. Keep meetings for the moments when real synchronous discussion is actually needed.

Bring Back RSS for Operational Security

Sun, 22 Mar 2026 11:02:00 +0100

Bring Back RSS for Operational Security

This post expands on ideas I previously presented at Pass the SALT 2024 in my talk Bring Back RSS For Operational Security.¹² The short version is simple: operational security teams still need a reliable way to track change, automate collection, and reduce dependency on closed platforms. RSS already solves much of that problem.

Operational security teams spend an enormous amount of time watching for change.

A new vulnerability advisory is published.
A vendor updates a CSAF document.
A threat actor leaks a new victim.
A trusted researcher posts a new analysis.
A CERT publishes an incident note.
A MISP event is enriched.
A public dashboard changes.

Most of these changes matter because they are new. And yet, in many security teams, we still collect this information in the most fragile way possible: by manually checking websites, relying on algorithmic social platforms, scraping pages that were never designed for machine consumption, or subscribing to closed platforms that add friction instead of removing it.

This is why RSS needs to come back in operational security.

Not as nostalgia. Not as a retro technology for bloggers. But as a simple, robust, auditable, automatable transport format for change detection and information sharing.

RSS was built for exactly this problem

RSS and Atom were designed to describe streams of updates: a list of items, each with metadata such as a title, a publication date, a link, and often a short description. In other words, they were designed to answer a basic operational question:

What changed since the last time I looked?

That question is at the heart of security operations.

A SOC does not only need raw telemetry. It also needs structured awareness of external change:

newly published vulnerabilities
changes in vendor advisories
new threat intelligence reports
updates from trusted researchers
public claims from threat actors
newly published forensic write-ups
software release notes with security impact
updates in shared intelligence platforms

RSS solves this in a way that is boring, open, and dependable. That is precisely why it remains useful.

Security operations need boring technology

Security teams already deal with enough complexity. We do not need every upstream source to invent its own notification model, API semantics, authentication flow, JavaScript-heavy frontend, and rate-limit strategy.

We need more sources that simply publish updates in a standard format.

RSS has several properties that make it especially attractive for operational use:

It is simple

The model is easy to understand: a feed contains entries. Each entry points to something new or changed. There is very little ambiguity about the purpose.

It is machine-readable

Feeds are meant to be consumed by software. This matters because security work quickly becomes repetitive at scale.

It is decentralized

There is no central platform that decides what is visible. Every producer can publish their own feed. Every consumer can subscribe using their own tooling.

It is automatable

Feeds can be polled, filtered, transformed, merged, archived, enriched, and redistributed with minimal effort.

It is auditable

Unlike opaque recommendation engines and engagement-driven timelines, RSS is explicit. You know what you subscribed to. You can replay entries. You can store them. You can build deterministic workflows around them.

In operational security, those properties are not just nice to have. They are essential.

Analyst fatigue is real, and RSS helps reduce it

Security analysts have a broad range of responsibilities: collecting events, detecting threats, triaging signals, analyzing context, and coordinating response. Repetitive collection work adds friction and contributes directly to fatigue. Automation is vital to keep humans focused on judgment rather than polling websites.¹

RSS is one of the easiest ways to automate the collection of external updates without building a fragile dependency on every source.

Instead of asking analysts to remember twenty websites, ten vendor portals, and a handful of social accounts, you can move to a model like this:

subscribe once
normalize once
filter continuously
alert selectively
archive automatically

That is a much healthier model for a SOC than “open browser tabs and refresh all morning.”

RSS is already useful in vulnerability management

One of the most obvious operational use cases is vulnerability intelligence.

The vulnerability ecosystem has changed significantly. NVD is no longer the only practical source of vulnerability information. We now have CNA publications, vendor advisories, CSAF feeds, project-level disclosures, and many other upstream sources. A modern vulnerability workflow must handle multiple sources, not just one canonical database.¹

This is exactly where feeds shine.

A multi-source vulnerability platform can expose a feed per source, allowing teams to:

monitor newly disclosed items
separate vendor-specific updates from generic CVE publication
follow only the ecosystems they care about
trigger enrichment or prioritization pipelines when new entries appear
generate internal dashboards or digests from the latest changes

In Vulnerability-Lookup, this model is natural: every source can expose recent updates through RSS or Atom, which makes it easy to subscribe, aggregate, and operationalize the latest disclosures.³⁴⁵

That matters because vulnerability operations are not only about querying a database. They are also about tracking what changed recently.

RSS is also a strong fit for threat intelligence collection

RSS should not be limited to vulnerability advisories.

Threat intelligence often starts with watching trusted public sources: researchers, incident responders, CERTs, vendor blogs, community projects, bot accounts, and public reporting streams.

A good example is Mastodon. By default, Mastodon accounts expose RSS feeds, which means public accounts can be consumed by standard feed tooling without depending on the platform interface. In practice, that makes it easy to subscribe to high-signal accounts and process updates automatically.¹

This creates useful possibilities:

track public ransomware victim disclosures
monitor researcher reporting on campaigns, malware, or infrastructure
watch topic-specific accounts for changes relevant to your organization
filter by keywords, sectors, product names, or geography
capture public reporting into internal knowledge systems

This is often more reliable than asking analysts to watch social media timelines manually.

RSS works well as an operational building block

One reason RSS deserves a comeback is that it composes well.

It does not need to be the final destination. It can be the transport layer between a source and your workflows.

For example:

Feed -> filter -> dashboard

A self-hosted reader can aggregate feeds from vendors, CERTs, researchers, and internal sources. Analysts can use this as a shared situational-awareness layer.⁶

Feed -> transform -> alert

A script can parse entries, match on keywords, extract URLs, and generate notifications only for relevant updates.⁷

Feed -> enrich -> MISP

A workflow can ingest feed items, pull linked content, create or update MISP events, and extract indicators or context from the referenced material.⁸

Feed -> merge -> publish

Multiple feeds can be combined into a reverse-chronological stream for a team portal, internal digest, or external situational-awareness page.⁹

Feed -> archive -> search

Entries can be stored over time, indexed, and replayed later for investigations, reporting, and retrospective analysis.

That modularity is one of RSS’s biggest strengths. It is not trying to be the whole platform. It is a small, useful component that fits into many platforms.

We should stop confusing “old” with “obsolete”

A recurring mistake in technology is assuming that older protocols are irrelevant simply because they are not fashionable.

RSS is old. So is email. So is DNS. So is syslog.

Age is not a good reason to discard a protocol that still solves a real problem effectively.

In fact, RSS compares favorably to many modern alternatives:

it is easier to consume than most bespoke APIs
it is easier to preserve than social media streams
it is more interoperable than proprietary notification systems
it is easier to self-host than most “intelligence platform” workflows
it creates less lock-in than platform-native feeds and dashboards

The security community often talks about resilience, open standards, and reducing dependency on single vendors. RSS is aligned with all three.

Practical use cases for operational security teams

Here are concrete places where RSS can provide immediate value:

Vendor advisory monitoring

Subscribe to vendor advisory feeds, product security feeds, and CSAF-derived updates. Route them to product owners, vulnerability teams, or sector-specific analysts.

CERT and CSIRT awareness

Track advisories, incident notes, and vulnerability communications from national and sectoral CERTs.

Research monitoring

Follow high-signal blogs, project release feeds, and public researcher accounts.

Threat actor visibility

In some cases, public reporting streams or bot-published updates can be monitored via RSS for early awareness and trend tracking.

Internal SOC dashboarding

Use a self-hosted feed reader or custom dashboard as a collaborative stream of external operational context.

MISP enrichment workflows

Consume feeds, extract linked content, and create or enrich events with contextual reports and indicators.

Executive or sector digests

Merge multiple feeds and publish filtered summaries in text, HTML, or Markdown for targeted internal audiences.

The tooling barrier is very low

Another reason to bring RSS back is that the tooling required is minimal.

You do not need a huge platform migration to start using it well.

A small stack can already deliver a lot of value:

a self-hosted reader for aggregation and sharing
a few scripts for filtering or transformation
MISP integration for enrichment and extraction
a merger tool for combined output
a discovery tool to find feeds on target sites

This is attractive for small and medium teams because the cost of experimentation is low. It is also attractive for larger teams because the result is transparent and composable.

There is no mystery box here. Just feeds, parsers, filters, and workflows.

RSS supports open security ecosystems

Operational security benefits when information can move between communities, tools, and organizations with as little friction as possible.

RSS supports that goal because it is:

open
well understood
easy to generate
easy to mirror
easy to transform
easy to redistribute

That makes it a good fit not only for consumption, but also for publication.

Security projects should publish feeds by default.

If you operate any of the following, you should consider exposing an RSS or Atom feed:

vulnerability databases
advisory portals
research blogs
release notes
incident summaries
MISP exports or derived views
sector-specific intelligence summaries
curated watchlists
public dashboards of recent changes

Publishing a feed is a simple way to make your information more usable operationally.

What the security community should do next

Bringing RSS back does not require a grand initiative. It requires a change in defaults.

If you produce information

Publish a feed.

Do not force users to scrape your site or depend on a proprietary platform just to know what changed.

If you build tools

Support feeds as both input and output.

Do not assume every workflow starts with a REST API and ends in a web UI.

If you run a SOC or CSIRT

Treat feeds as first-class operational inputs, not as a side channel.

Build subscription, filtering, enrichment, and archival workflows around them.

Make RSS and Atom part of the interoperability story again.

Simple export formats often have the biggest practical impact.

RSS is not dead. We just stopped using it enough.

RSS never disappeared. It was simply pushed to the margins while platforms optimized for attention, lock-in, and opacity.

But in operational security, those platform incentives are often the opposite of what we need.

We need explicit subscriptions instead of algorithmic ranking.
We need structured updates instead of noisy timelines.
We need automation instead of manual checking.
We need open formats instead of closed ecosystems.

RSS still provides that.

So yes, bring back RSS for operational security.

Not because it is old-school. Because it is useful. Because it is interoperable. Because it reduces friction. Because it helps analysts focus on what matters. And because a lot of security information is, at its core, simply a stream of changes that deserves a clean and standard way to be consumed.

Footnotes

Pass the SALT 2024 slides, Bring Back RSS For Operational Security: https://www.vulnerability-lookup.org/files/events/2024/20240603-bring-back-rss-for-operational-security.pdf ↩ ↩² ↩³ ↩⁴
Pass the SALT 2024 recording: https://passthesalt.ubicast.tv/videos/2024-bring-back-rss-for-operational-security/ ↩
Vulnerability-Lookup project: https://github.com/cve-search/vulnerability-lookup ↩
Example recent NVD Atom feed: https://vulnerability.circl.lu/recent/nvd.atom ↩
Example recent Siemens CSAF RSS feed: https://vulnerability.circl.lu/recent/csaf_siemens.rss ↩
Newspipe: https://github.com/cedricbonhomme/newspipe ↩
RSS tools collection: https://github.com/adulau/rss-tools ↩
MISP scraper blog post: https://www.misp-project.org/2022/08/08/MISP-scraper.html/ ↩
rssmerge.py example: https://github.com/adulau/rss-tools/blob/master/bin/rssmerge.py ↩

Open Contributions Descriptor — or how to map your contribution in open source, open data, and open standards

Sun, 01 Mar 2026 11:02:00 +0100

Open Contributions Descriptor — or how to map your contribution in open source, open data, and open standards

Open ecosystems thrive on collaboration. Open source software, open data initiatives, and open standards communities all depend on a complex web of contributors, maintainers, organizations, and users working together across domains and borders.

Yet, despite this openness, one surprisingly difficult question remains:

Who contributes what — and how can others participate?

The Open Contributions Descriptor (OCD) was designed to answer exactly that question.

This post explains the story behind the Open Contributions Descriptor, the problem it aims to solve, and how it helps map contributions across the open ecosystem in a way that is both human readable and machine actionable.

Where the idea started

The Open Contributions Descriptor did not emerge in isolation.

The original inspiration came from Mozilla’s contribute.json initiative: https://github.com/mozilla/contribute.json.

Mozilla introduced the idea that projects could publish a small machine readable file describing how people could contribute. It was a simple but powerful concept: contribution entry points should be discoverable automatically rather than buried inside documentation.

Although the project is now archived, the underlying idea remained compelling:

Contribution information should be structured, portable, and published by the project itself.

The Open Contributions Descriptor expands this original vision beyond onboarding contributors to a single project and generalizes it across:

open source
open data
open standards
broader open ecosystems

In a way, Open Contributions Descriptor (OCD) can be seen as a natural evolution of that early experiment, extending contribution metadata from project contribution guidance to ecosystem mapping.

The problem: visibility in a fragmented open ecosystem

Open ecosystems are rich but fragmented¹.

Today, information about contributions is scattered across many places:

Git repositories
README files
governance documents
mailing lists
project websites
data portals
standards organizations
issue trackers
funding reports

Each project documents participation differently or sometimes not at all.

As a result:

Contributors struggle to understand how to get involved.
Organizations cannot easily demonstrate their open contributions.
Communities lack visibility into dependencies and relationships.
Researchers and policymakers cannot map the real impact of openness.
Automated catalogues of open initiatives are difficult to build.

Ironically, while open projects publish code and data transparently, the structure of contributions themselves remains opaque or unknown.

A recurring realization at FOSDEM

Every year, attending FOSDEM is an inspiring experience.

Walking through the corridors, talking to maintainers, and visiting project stands inevitably leads to the same realization:

I constantly discover mature, impactful open source projects I had never encountered online before.

Projects with active communities, real deployments, and years of development somehow remain invisible to traditional discovery mechanisms.

They exist. They are open. They are active.

Yet they are hard to find unless you physically meet the people behind them.

This recurring experience highlights a missing piece in the open ecosystem:

the discovery layer is incomplete.

Search engines index code. Platforms index repositories. Conferences reveal communities. But there is no universal, structured way for projects to declare:

who they are
how they operate
how others can participate

There is a missing key, not to access the code, but to understand the collaboration around it.

Beyond open source: a shared challenge

The challenge is not limited to software.

Across ecosystems we see similar issues:

Domain	Example Questions
Open Source	Who maintains the project? Who funds development?
Open Data	Who produces the dataset? Who curates it?
Open Standards	Who participates in working groups? Who implements the standard?
Research	Which institutions contribute to which initiatives?

These domains overlap constantly. A single organization may:

maintain open source tools
publish open datasets
contribute to standards bodies
depend on other open projects

But there is no simple, structured way to describe these relationships consistently.

The hidden structural problem: centralized directories

Another, less visible issue exists in today’s open ecosystem: centralized discovery.

Many catalogues, registries, and directories attempt to index open projects. While useful, they often share a structural limitation:

A single platform or organization becomes the gatekeeper of discovery.

In practice, this means:

inclusion depends on platform policies
metadata formats are platform specific
projects must register manually
ecosystem visibility depends on maintaining accounts in external systems
long term sustainability relies on the continued existence of one operator

Even in open ecosystems, discovery frequently depends on a central directory holding the “golden key” to visibility.

This creates several risks:

single points of failure
loss of neutrality
vendor or platform lock in
incomplete ecosystem representation
barriers for smaller or independent initiatives

Openness should not depend on a single registry.

The idea: describe contributions as first class metadata

The Open Contributions Descriptor (OCD) introduces a simple idea:

Contributions themselves should be described using an open, structured, machine readable format published directly by the project.

Instead of embedding contribution information informally in documentation, projects publish a descriptor file that answers:

What is this initiative?
What type of openness does it represent?
Who contributes?
How can others contribute?
What roles exist?
How are decisions made?
Where are the contribution entry points?

The goal is not to replace existing documentation but to standardize discovery and mapping.

A standardized discovery location

To make automated discovery reliable, the descriptor is published in a predictable location using a well known URI.

The Open Contributions Descriptor (OCD) is stored as a JSON document named:

.well-known/open-contributions.json

This follows the established .well-known convention defined by RFC 8615, which allows services and metadata to be discovered automatically at standardized paths on a domain.

By placing the descriptor at a well known location:

crawlers know exactly where to look
projects remain in control of their metadata
discovery becomes interoperable across platforms
no registration in external directories is required

To formalize this approach, a registration request for the open-contributions.json well known URI has been submitted to IANA:

https://github.com/protocol-registries/well-known-uris/issues/78

This step is important because it moves the descriptor from an informal convention toward an Internet recognized discovery mechanism, reinforcing long term interoperability and neutrality.

Decentralized discovery by design

A key property of the Open Contributions Descriptor is directory independence.

The descriptor lives with the project or organization itself, not inside a centralized platform.

This changes the discovery model fundamentally:

Traditional Model	OCD Model
Register project in a directory	Publish descriptor in repository
Directory owns metadata	Project owns metadata
Central authority curates	Anyone can crawl
One catalogue	Many interoperable catalogues
Platform dependency	Ecosystem independence

Anyone can build a crawler that discovers descriptors across repositories, websites, or data portals.

There is no central registry required.

Multiple catalogues can coexist:

research indexes
public sector inventories
community driven directories
organizational dashboards
academic analysis platforms

This mirrors the architecture of the web itself:

No single organization owns websites. Search engines discover them.

The Open Contributions Descriptor applies the same philosophy to open collaboration.

Design principles

When designing the Open Contributions Descriptor, several principles guided the work.

Domain agnostic openness

The format works across:

open source
open data
open standards
open research
open infrastructure

It avoids domain specific assumptions while remaining expressive.

Human readable first

The descriptor is meant to be understandable without tooling.

A contributor should be able to open the file and immediately understand:

who is involved
how participation works
where contributions happen

Machine readable by design

At the same time, the format is structured so that tools can easily:

parse descriptors
crawl repositories
build catalogues
map ecosystems
analyze contribution networks

This enables automation without sacrificing clarity.

Lightweight adoption

Projects should not need governance reform to describe themselves.

Many existing directories and metadata formats are designed by committees attempting to normalize the diversity of open ecosystems through rigid governance models. While often well intentioned, they tend to introduce complex requirements, mandatory classifications, approval workflows, or artificial eligibility rules that projects must satisfy before being listed.

In practice, this leads to several problems:

projects must adapt their governance to fit the directory rather than the reverse
contributors spend time complying with administrative requirements instead of building software or data
smaller or unconventional projects are excluded because they do not match predefined models
innovation is constrained by bureaucratic assumptions about how projects should operate

Over time, such rules unintentionally reduce the usefulness of directories themselves. The more constraints imposed, the less representative the catalogue becomes.

The Open Contributions Descriptor takes the opposite approach.

Instead of committees defining how projects must behave, projects simply describe how they already work.

There is:

no approval process
no governance validation
no mandatory organizational structure
no centralized interpretation of legitimacy

The descriptor lowers the barrier to participation by adapting to reality rather than attempting to standardize it.

Independence and sovereignty

Perhaps most importantly:

Projects remain sovereign over how they describe themselves.

No platform approval is required. No centralized authority controls visibility. No organization holds the authoritative directory.

Descriptors enable an ecosystem where discovery emerges organically from openly published metadata.

What the Open Contributions Descriptor enables

Mapping the open ecosystem

Imagine being able to automatically discover:

all projects maintained by a given organization
datasets linked to specific software
standards implemented by certain communities
contribution entry points across ecosystems

Descriptors allow building living maps of openness without centralized ownership.

Easier onboarding for contributors

New contributors often ask:

Where do I start?
Who should I contact?
What skills are needed?
How do decisions work?

Instead of searching multiple documents, a descriptor provides a structured overview.

Transparency and recognition

Organizations increasingly want to demonstrate their participation in open ecosystems.

The descriptor allows them to clearly expose:

roles
responsibilities
contributions
collaboration models

This improves recognition without requiring manual reporting or third party platforms.

Machine discoverable catalogues, plural not singular

One of the core objectives is enabling automated catalogues of:

open source projects
open datasets
open standards initiatives

Importantly, there is not one catalogue. Anyone can build one. Competition, diversity, and experimentation become possible because the metadata layer is open and decentralized.

A simple mental model

Think of the Open Contributions Descriptor as:

package.json for contributions
robots.txt for openness
metadata for collaboration
DNS for open participation

It tells both humans and machines:

“Here is how this open initiative works and how you can participate.”

Example use cases

Open source project

A project publishes an OCD file (MISP project open-contributions.json file) describing:

maintainers and governance
contribution guidelines
communication channels
funding or supporting organizations

Tools can automatically include it in multiple independent catalogues.

Open data platform

A dataset provider describes:

data producers
curators
update responsibilities
contribution workflows
licensing and reuse expectations

Researchers can discover participation opportunities instantly.

Open standards working group

A standards initiative describes:

working groups
participation model
implementation communities
decision processes

Implementers gain clarity without navigating institutional silos.

Why a standard matters

Without a shared descriptor:

every ecosystem reinvents metadata
automation becomes brittle
discovery remains centralized or manual

A common format enables interoperability between communities that historically evolved separately but now collaborate closely.

The Open Contributions Descriptor aims to become a common language for openness without central control.

Open by design

The specification itself is openly developed and available here:

https://github.com/ossbase-org/Open-Contributions-Descriptor

The goal is community driven evolution:

feedback from open source maintainers
adoption by open data platforms
experimentation by standards bodies
tooling built by ecosystem builders

What comes next

The real value of the Open Contributions Descriptor will emerge through adoption and tooling, including:

decentralized ecosystem crawlers
contribution dashboards
organizational impact mapping
research analysis
federated discovery platforms

We envision a future where understanding the open ecosystem becomes as easy as querying a search engine, powered by structured contribution metadata published at the source.

Conclusion

Open ecosystems depend on collaboration, but collaboration itself is still poorly described and too often centrally indexed.

The Open Contributions Descriptor is a small but important step toward making openness discoverable, understandable, decentralized, and measurable.

By standardizing how contributions are described, we can:

lower barriers to participation
increase transparency
preserve ecosystem independence
avoid centralized gatekeeping
recognize contributors
map the global landscape of open collaboration

If open source made code visible, and open data made information visible, the next step is clear:

Make contributions visible without giving anyone the golden key.

Contributions, feedback, and experimentation are welcome because describing openness should itself be open.

Git repository of the Open Contributions Descriptor: https://github.com/ossbase-org/Open-Contributions-Descriptor
Online tool to browse or create/edit Open Contributions Descriptor file: https://ossbase-org.github.io/ocd-viewer/app/home.html - Git repository https://github.com/ossbase-org/ocd-viewer
GitHub organisation generator to Open Contribution Descriptor format: https://github.com/ossbase-org/Open-Contributions-Descriptor/blob/main/bin/github-to-ocd.py
Discourse topic about OCD format.
A sample OCD file for the MISP project.

The term fragmented is often perceived negatively, suggesting disorder or inefficiency. In open ecosystems, however, fragmentation is largely a strength. It reflects diversity, independence, resilience, and experimentation across communities rather than centralized control. The challenge is therefore not to eliminate fragmentation, but to make it discoverable and understandable without reducing its autonomy. ↩

Acknowledging Reality in Vulnerability Disclosure

Sun, 08 Feb 2026 13:02:00 +0100

Full Disclosure Still Exists and That’s Exactly the Point

Disclaimer: This post is grounded in personal experience and roughly 25 years of interaction with vulnerability management, across vendors, researchers, operators, CERTs, and open communities. It does not claim neutrality or theoretical purity. It reflects what repeatedly emerges when disclosure leaves policy documents and meets reality. In other words, this is my bloody personal blog, not an official statement.

Every few years, vulnerability disclosure is declared settled. We are told that the ecosystem has matured, that coordinated disclosure is the answer, and that whatever remains outside this model is either irresponsible, obsolete, or simply irrelevant.

And yet, full disclosure is still here.

Not as a historical artifact, not as a provocation but as an active, lived practice that continues to coexist with other disclosure models.

This blog post explains why this coexistence matters, why the evolution of vulnerability disclosure is not linear, and why initiatives like GCVE deliberately choose to support all disclosure models instead of promoting a single “correct” one.

The Myth of Linear Progress in Disclosure

A common narrative goes like this:

We started with full disclosure → we learned better → we now do responsible or coordinated disclosure.

This framing is comforting. It suggests progress, maturity, and consensus. It is also misleading.

In reality, vulnerability disclosure did not evolve along a single axis.

What we have instead is a non-linear space of practices, shaped by:

Legal constraints
Power asymmetries
Time pressure
Risk tolerance
Economic incentives

The disclosure landscape includes, and continues to include:

Full disclosure
Responsible disclosure
Coordinated disclosure
Vendor-led disclosure
Third-party publication
Silent or delayed disclosure
Federated or community-driven publication

These models exist in parallel, not as steps in a staircase.
They are chosen, combined, or abandoned depending on context.

Economics: The Hidden Driver of Disclosure Models

Vulnerability disclosure is not only a technical or ethical process.
It is also an economic one.

Disclosure mechanisms range from:

Gratis, volunteer-driven reporting
Academic or community research
Contractual security assessments
Paid vulnerability programs
Expensive, highly structured bug bounty processes

Each of these comes with:

Different expectations
Different timelines
Different power relationships
Different notions of “responsibility”

A researcher working for free does not operate under the same constraints as:

A consultant under contract
A bug bounty hunter optimizing return on investment
A vendor-funded security team

Economic incentives shape:

When vulnerabilities are disclosed
To whom they are disclosed
Under what conditions
With what level of detail

Ignoring this economic dimension leads to unrealistic disclosure policies that assume goodwill, time, and resources are evenly distributed. They are not.

Actors Are Not Rational and Not Aligned

Another recurring simplification is the idea that vulnerability disclosure is a cooperative game between rational actors working toward the same goal.

It is not.

Vendors balance security, liability, brand perception, and business continuity.
Researchers operate under ethical pressure, legal uncertainty, time constraints, and economic reality.
Users are downstream actors with limited visibility and little bargaining power.
Intermediaries (CERTs, CSIRTs, platforms) act under mandates that vary widely across jurisdictions.

These actors do not share the same incentives, and they are not playing the same game.

So when someone says:

“The legal framework will solve it”
“Just do coordinated disclosure”
“If it’s not coordinated, it doesn’t exist”

What they are really doing is reducing the problem space to the subset they are comfortable managing.

The remaining cases do not vanish. They simply become unaccounted for.

Why GCVE Exists

GCVE was not created to replace existing identifiers, processes, or disclosure norms.

It was created to support all disclosure models, including:

Centralized systems
Decentralized or federated approaches
Vendor-driven workflows
Independent or community-based publication

GCVE explicitly does not take sides in these tensions.

Instead, it assumes something pragmatic:

Vulnerability information exists regardless of how or whether it was disclosed “properly”.

The purpose of GCVE is not to normalize behavior, but to ensure that once vulnerability information exists, it can be referenced, processed, and consumed.

Ignoring inconvenient disclosures does not improve security. It only weakens collective awareness.

Freedom, Accessibility, and Security Intelligence

One of the more controversial aspects of GCVE is the level of freedom it gives to GNAs (GCVE Numbering Authorities).

This freedom is deliberate.

Cybersecurity intelligence does not improve by keeping information unknown.
It improves through accessibility, correlation, and contextualization.

For users, defenders, and analysts, the central question is not:

“Was this vulnerability disclosed in the ideal way?”

It is:

“Can this vulnerability affect me, my systems, or my dependencies?”

Without accessible information:

Risk cannot be evaluated
Impact cannot be assessed
Mitigations cannot be prioritized and performed

GCVE is built on the idea that users must be able to access vulnerability information, even when the disclosure path is imperfect, contested, or economically asymmetric.

Freedom here does not mean absence of accountability.
It means not blocking information at the source, while allowing consumers to decide how to interpret and trust it.

Why GCVE Uses BCPs Instead of Enforcement

A frequent question is:

Why don’t you require GNAs to follow strict rules?

Because strict enforcement inevitably creates:

Gatekeepers
Central authority
Single points of failure
Implicit power over publication

GCVE instead defines Best Current Practices (BCPs):

Descriptive rather than prescriptive
Transparent rather than coercive
Evolvable rather than rigid

This approach does not prevent:

Public evaluation of GNAs
Rating or scoring their behavior
Highlighting poor or exemplary practices
Making trust an explicit, visible signal

What it avoids is using access control as governance.

Freedom is uncomfortable (and many of us know that fact). It allows outcomes that some actors will strongly disagree with.

But it also allows vulnerability information to exist before consensus, outside institutional comfort zones, and without requiring permission.

“Federation Is Dangerous”, We’ve Heard This Before

Some criticism around GCVE focuses on the perceived danger of federation: fragmentation, balkanisation, loss of control.

These arguments are not new.

They closely mirror the concerns raised when Git was introduced:

“It will fragment codebases” The Promises and Perils of Mining GitHub, 2014
“There will be no single source of truth” Version Control Tools, Martin Fowler, 2010
“People will do the wrong thing” What’s Wrong with Git? A Conceptual Design Analysis, 2013

History suggests otherwise. Federation does not remove coordination it relocates it.

And to be clear: GCVE does not mandate federation.
Centralized models remain fully supported.

As a side note: if GCVE reaches even 1% of Git’s success, we would already consider that a major achievement. (Yes, that is both a joke and a realistic benchmark.)

GCVE and a Non-Reductionist View of Disclosure

Saying “this disclosure model no longer exists” does not make it true.
It only narrows the analytical lens.

GCVE takes a non-reductionist approach by focusing on what vulnerability information needs in practice:

Machine-readability
Stable identifiers
Open formats
Automatic processing
Interoperability across tools and ecosystems

GCVE is designed as an open standard enabling:

Correlation across datasets
Automated ingestion
Enrichment by third parties
Integration into security tooling

This applies equally to:

Proprietary software
Open source software
Hybrid supply chains
Federated ecosystems

The objective is not to enforce a single disclosure workflow, but to ensure that all vulnerability information (regardless of origin, model, or economic context) can participate in the same analytical space.

Complexity Is the Reality. Not the Problem.

Vulnerability disclosure is messy. It is legal, economic, technical, political, and human.

Any framework that assumes otherwise will fail at the margins — precisely where many real-world vulnerabilities exist.

GCVE does not attempt to simplify this reality away.
It attempts to acknowledge it, structure it, and make it usable.

Not by declaring one model correct,
but by accepting that security depends on visibility, not denial.

That is not a weakness.

It is the point.

The Art of Pivoting - Techniques for Intelligence Analysts to Discover New Relationships in a Complex World

Sat, 20 Dec 2025 09:02:00 +0100

This open source book explores how intelligence and cyber-security analysts can uncover hidden links between threat actor infrastructure and ongoing investigations by pivoting on both classic and unconventional indicators — many of which are often overlooked. The material is grounded in empirical, field-tested strategies used in cyber-security, digital forensics, cyber threat intelligence, and intelligence analysis more broadly.

I released the first version of this book following the FIRST.org CTI Conference 2025 in Berlin, where the initial idea for the project emerged.

Our goal is to provide analysts with a practical toolkit of analytical methods, supported by real-world examples, to enhance investigative workflows without locking them into a single mindset, strict model, or overly rigid technical strategy. Instead, the book encourages creative exploration, data-driven reasoning, and the use of diverse data points — from traditional IOCs to subtle metadata traces — as part of a flexible and repeatable analytical process.

The approach presented throughout this book is intentionally built upon open-source tooling, most notably the MISP threat intelligence platform and the AIL Project. By relying on transparent and widely adopted tools, every technique described here can be reproduced, validated, and reused by analysts, researchers, educators, or incident response teams. This ensures that the methodology is not theoretical or proprietary, but openly verifiable, community-driven, and designed to evolve. The book itself follows the same philosophy: it is an open, living document, publicly versioned, and contributions are welcomed directly via Git. Readers are encouraged to experiment, improve, and extend the content, making the entire workflow repeatable, auditable, and collaborative within the wider defensive security community.

Background Story

This book grew out of an iterative, hands-on process tightly coupled with our day-to-day work. Rather than starting from a fixed theory, it evolved alongside real investigations—tracking threat actors, uncovering infrastructure, and experimenting with unconventional pivoting techniques as new challenges emerged.

Each discovery fed back into our tooling: ideas were tested, adjusted, sometimes discarded, and often refined through repeated use. This constant loop of observation, experimentation, and validation shaped both the content of the book and the evolution of the tools supporting it.

Much of this work happened in motion—on trains during daily commutes, between incidents, or while reviewing fresh data. That constraint encouraged pragmatism: techniques had to be simple enough to apply quickly, yet powerful enough to reveal meaningful connections. The result is a book that reflects continuous learning in practice, grounded in real-world analysis rather than static models.

🔗 PDF - The Art of Pivoting
🔗 Source of the book in Markdown (if you want to contribute ;-)

How to Choose an Open Source Project for the Long Term

Sun, 25 May 2025 10:02:00 +0200

How to Choose an Open Source Project for the Long Term

version 1.0 - 25th May 2025

Many of us face the challenge of selecting open source projects for long-term use. This could involve choosing dependencies for your own open source project, or simply selecting software you plan to run and rely on over time.

After experiencing multiple failures, disappointments with projects that turned proprietary, or even the complete disappearance of some repositories, I decided to compile a list of parameters, indicators, and signals that might help identify solid, sustainable open source projects, as well as warning signs that could indicate potential risks.

CLA - Contributor License Agreement

One of the first and most important parameters to consider is the CLA (Contributor License Agreement). As you may know, a CLA is a legal tool but it can be misused to lock in contributions while allowing the original creator (often an organization, but not always) to relicense the work under any terms they choose.

In my personal experience with CLAs over the past 25 years, CLAs are just tools invented by lawyers to exploit human contributions.

If you see a CLA in an open source project, it’s already a strong signal that the project might eventually be relicensed, shift its objectives, or even be rebranded by a commercial entity that views open source merely as a marketing vehicle and nothing more.

If someone tells you that a CLA is there to protect you and your contributions, it’s complete bullshit. Honestly, the CLA was one of the biggest screw-ups of the FSF, it legitimized a bad practice and gave corporate borgs a free pass to exploit it for years. If you want to dig deeper, check out these excellent resources: Why Your Project Doesn’t Need a Contributor Licensing Agreement, the CLA-Free Initiative, and Seriously, don’t sign a CLA.

Software can also be proprietarized even without a CLA just like it happened with Benthos. But CLAs are usually there to protect organizations, not contributors, especially shielding them from potential litigation. So yes, CLAs are strong indicators of possible bad practices down the road.

On the other hand, seeing a DCO (Developer Certificate of Origin) is usually a good sign. It’s not a transfer of ownership, but simply a statement that you agree (and have the right) to have your contribution included in the open source project.

From a contributor’s perspective, this is a positive sign, it shows that contributors are respected and that the project is focused on building a healthy, sustainable community for the long term.

Does the project merge pull requests from outside their organization?

It’s very common to see projects run by a specific organization that don’t accept any contributions from external contributors, only merging pull requests from authors within their own company. Even good contributions often get rewritten, and the original pull request is closed with a comment saying it was “merged,” even though it wasn’t.

This is a classic tactic used by organizations that avoid CLAs just to appear friendly to contributors, while still sidestepping legal risk and keeping full ownership of the codebase which makes relicensing easier down the line.

Does the project interact with contributors and especially how?

Another strong indicator of a project’s long-term health is how it interacts with contributors. Are external contributors welcomed into the development process, or are they quietly pushed aside? Are they included in discussions about design decisions or the direction of a pull request, or is everything decided behind closed doors?

Pay attention to how the maintainers respond to contributions. When a pull request is rejected, is there a respectful, constructive explanation, or just silence or a vague dismissal? Do maintainers engage with feedback and questions in the issue tracker or discussion forums?

A healthy open source project values its community. Transparency, respectful communication, and public discussions are signs of a project that is likely to grow and survive. If you see a pattern of gatekeeping, dismissiveness, or lack of documentation around decision-making, that’s a red flag for long-term sustainability.

Is the open source license a strong indicator of sustainability?

At first, I used to think that using a copyleft-style license was a strong sign of long-term sustainability. But nowadays, I’d say it’s not a reliable indicator on its own.

Of course, the license should be a proper free license, approved by the FSF or OSI, but that’s just the baseline for choosing an open source project. The type of open source license alone doesn’t guarantee longevity or a healthy project.

Summary

If you see a CLA, avoid the project, especially if you need to rely on it for the long term.
If you see projects that never merge contributions and instead rewrite them, stay away, they’re a bad bet for long-term use.
If a project’s handling of contributions is hidden behind closed doors, that’s another clear reason to avoid it.

Additional Notes

I may update this article from time to time to add more strong indicators that can help others choose and evaluate open source projects for long-term use.
Can these indicators be automatically analyzed to create a scoring system for open source projects? I don’t think so, there’s a strong element of perception and context in this kind of analysis. And honestly, I suspect organizations would quickly start gaming the system just to get a better score.

Le Sillon Fictionnel en livret PDF et EPUB

Sun, 23 Feb 2025 15:02:00 +0100

J’ai toujours des idées à la con… Il y avait une issue sur GitHub pour créer un petit livret en PDF et EPUB de notre brol sillonesque. L’optimisme est toujours l’apanage des fous. Comme le chat n’était pas en super forme, je me suis dit que travailler sur l’ordinateur serait facile tout en lui tenant compagnie.

Je commence en me disant qu’une conversion de pages HTML vers un livre PDF serait simple. C’était sans compter l’essence même d’un site web avec des pages en Markdown. Ces pages sont uniques. Concaténer n’est pas une solution. Donc, on démarre avec un petit programme Python pour rassembler le tout.

Puis viennent les notes de bas de page avec des références uniques… On se dit qu’il suffit d’une indexation globale, rien de bien méchant. On pense : « OK, il reste 10 minutes et c’est ficelé. » Mais là, on se rend compte que la conversion Markdown vers LaTeX, c’est bien, sauf qu’il faut retravailler le TeX pour rendre le tout lisible… et puis survient le cauchemar des tailles et formats d’images.

L’optimisme reprend le dessus grâce au super logiciel libre Pandoc… On avance, mais les images restent un foutoir innommable. On découvre que Pandoc fait du Lua et qu’on peut filtrer/modifier les figures. Allez, on se remet au Lua. Puis on tombe sur d’autres joyeusetés, comme la police EB Garamond qui ne passe pas via Fontconfig… et j’en passe.

Mais au final, après quatre litres de thé noir du Mozambique, un chat qui vous fixe bizarrement et quelques expérimentations, ça fonctionne ! Avec, en prime, Le Sillon au format EPUB pour les liseuses.

Gaining Visibility in the Algorithmic-based Internet by Reclaiming Your Space

Thu, 02 Jan 2025 15:01:00 +0100

If you are writing, one of your primary objectives is to be seen and read—two distinct but interconnected goals. Visibility helps your work reach a wider audience, which can lead to more readers engaging with your content. However, in today’s Internet landscape, visibility is shaped by algorithms on social networks, search engines, and advertising networks. These systems often prioritize content that aligns with their business interests, rather than purely the quality or relevance of the material.

The traditional bookstore model offers an insightful comparison. In the past, a bookseller might carefully curate their inventory based on relationships with publishers or their own judgment of quality and market interest. As a reader, you could walk into a bookshop, browse the shelves, or explore a table displaying new releases. Often, a thoughtful recommendation from the bookseller could guide your choice. If a book sparked your curiosity, you might purchase it, and, if it resonated, spend time reading and reflecting on its reading.

In the algorithmic age, or perhaps more accurately, the digital advertising age, the human touch of discovery has been replaced by calculated exposure. Content is surfaced not by serendipity or personal curation but by systems optimised to serve business objectives, often prioritizing engagement metrics over quality.

We often hear that to stand out in this environment, authors or writers must adopt a strategic approach, blending authenticity with a deep understanding of how algorithms operate. To be honest, that’s complete bullshit. The content that is most visible today is rarely the most authentic or useful. It’s simply the content that can generate clicks and capture brain time for advertisers.

I recently rediscovered an old backup of logs from my web server from the early 2000s and compared them with the current logs from 2024. The differences are striking. Back then, around 80% of the access was generated by actual users opening URLs in their browsers, while the remaining 20% was machine crawling or other noise.

Today (2024), noise accounts for 90% of the accesses to my blog posts. This noise primarily comes from:

Trending bots attempting to determine whether a link is interesting enough to include in their algorithms to notify customers that the information is relevant. Companies like Hootsuite, Zoho, Ahref/Yep and many others operate in this space—though I suspect they rarely, if ever, actually read the content. It seems more about branding trends than genuine readers engagement.
Aggressive crawling bots, often associated with AI or linguistic projects, use user-agents reference that provide vague or meaningless explanations of their purpose. Companies like Facebook and Amazon are among the most common in this space. However, it’s clear that your writing will never actually appear on their platforms—it’s simply harvested to serve their data-gathering efforts and refine their own content.
Search engine bots, like Google’s, crawl your pages and might include them in their index weeks or months later. However, don’t expect to appear in the top ten results unless your content is an exact match—and even then, if you’re not part of their advertising network, you’re likely out. On a side note, the SEO industry has effectively destroyed and fucked-up the organic nature of the Internet.
Security bots brute-force attempts, which are increasingly difficult to differentiate from legitimate activity. Many security vendors operate across multiple domains, including exploitation or reselling their data feeds for purposes beyond simply notifying website owners of vulnerabilities.
Mastodon “pre-fetching” URLs, which provides no indication of how many people actually read the content. The overhead can be significant, especially if your post is boosted by an account with many followers, as it’s simply the Fediverse server performing a GET request. Out of curiosity, I analysed a specific URL that was shared only on the Fediverse. It received approximately 34,000 GET requests, yet this translated to just two actual users reading the content.
Pre-fetching bots designed to display your content within ad-supported interfaces. This practice is increasingly common, with bots often testing how the content fits different devices. Unsurprisingly, this doesn’t benefit the content creator in any meaningful way. Instead, it’s aimed at keeping users within the ad-supported application, preventing them from venturing into the broader Internet beyond the confines of these advertising-driven ecosystems.

Less than 10% of the remaining entries in the logs represent actual users browsing and reading the content (and that’s without delving into questions about attention span or whether the content is truly read beyond the title). This 10% is an optimistic estimate based on this quick analysis.

How did we go from an Internet where 80% of the traffic came from genuine readers to a mere 10%, with the rest being noise? Have we really spent the last twenty years investing in Internet routing, bandwidth, server storage, hardware, and energy only to support access via advertising-gated platforms? In doing so, we’ve limited the original promise of the Internet: providing diversity and access to a wealth of knowledge.

What would be the strategy to return to the original promise of the Internet? Blogrolls, random access to blog posts or websites, RSS feeds, or perhaps running your own server? I’m still exploring, but I’m trying to contribute my part to that original vision.

We’ve set up a book club aligned with this promise called le sillon fictionnel. The site is now one year old, and we have 34 followers on Mastodon. According to the logs, we have some actual readers, despite the 95% of noise generated by bots.

Improving Cybersecurity Impact Taxonomies

Sun, 08 Dec 2024 01:01:00 +0100

Improving Cybersecurity Taxonomies Describing Impact and Cyber Harms Against Organizations

If you work in the cybersecurity field, the term impact is ubiquitous, appearing frequently in information security regulations such as NIS2 (and previously NIS1). It plays a critical role in reporting obligations and the definition of a significant cyber threat.

The definition and classification of impact have been subjects of debate for some time. I recently incorporated a MISP taxonomy inspired by a 2018 publication titled “A taxonomy of cyber-harms: Defining the impacts of cyber-attacks and understanding how they propagate.” This publication offers a detailed taxonomy of cyber-harms experienced by organizations, helping to better define and classify the impacts of cyber-attacks.

If you are incident responder or DFIR practioners, it’s giving a good way to classify the impact of what you analyse or used as discussion source for the victims of the cyber attacks. Even within a SOC or CSIRT team, you can use consistent terminology to classify the actual impact.

The organizational cyber harms taxonomy is divided into several clear categories (predicates):

physical-digital
economic
psychological
reputational
social-societal

For example, the economic category provides a well-defined set of impacts that can be applied in various organizational contexts and cases, ranging from disrupted-operations and reduced-profits to pr-response-costs.

In 2015, when we began designing the MISP taxonomy format, we didn’t anticipate the widespread success of the misp-taxonomies repository. Today, it is widely used across various open source (and proprietary) threat intelligence tools, analytical projects, and open data classification initiatives.

If you use and/or manage a MISP instance, the taxonomy integration is seamless. You can choose to use one or more taxonomies, select specific parts (e.g., a single tag from a larger taxonomy), enforce their usage, run analytics on specific tags, or even filter API responses based on selected tags from the taxonomies.

The organizational cyber harms taxonomy provides a good basis for describing impact on specific events or incidents. This can be used in complement with

economical-impact is a taxonomy designed to describe the financial impact, whether as a positive or negative outcome, on the tagged information (e.g., data exfiltration loss representing a negative impact for the victim but a positive gain for an adversary).
nis2 is a taxonomy that includes impacted sectors, the severity of the impact (which is open to interpretation), and the impact outlook (e.g., whether it is increasing or decreasing over time).

An overview of the taxonomy as used in MISP:

My hope is that more organizations will share details about the impacts of their own events, as well as insights from other incidents. I understand this can be challenging, as sharing TTPs of threat actors is currently more widely accepted than sharing details about impacts. However, I truly hope this trend will shift, enabling more robust analytics and a clearer understanding of the actual impact of incidents—whether it is accurately represented or inflated. The formalized organizational cyber harms taxonomy provides a solid foundation for improving the description and analysis of impacts.

Don’t hesitate to propose new taxonomies or suggest improvements via the GitHub repository.

References

MISP Taxonomy: organizational-cyber-harm - A taxonomy for classifying organizational cyber harms based on categories such as physical, economic, psychological, reputational, and social/societal impacts in MISP standard format.
The MISP Taxonomies collaborative GitHub repository allows you to propose changes, updates, or corrections to the directory of taxonomies.

From Ruins to Resilience: How Developing and Utilizing Open Source Solutions Enhances CSIRT Capabilities

Sat, 12 Oct 2024 02:01:00 +0200

From Ruins to Resilience: How Developing and Utilizing Open Source Solutions Enhances CSIRT Capabilities

”Some cities have fallen into ruin and some are built upon ruins but others contain their own ruins while still growing.” Jeffrey Eugenides

Introduction

At CIRCL (Computer Incident Response Center Luxembourg), part of the Luxembourg House of Cybersecurity (LHC), we embarked on a journey to build and sustain open-source solutions for CSIRTs. With over 14 years of experience, we’ve gained valuable insights into open-source software development and community engagement in the cybersecurity field. Below are some of the key lessons we’ve learned along the way.

When you buy proprietary tools, you’re at the low end of both “doing” and “capabilities.” You rely on external vendors, and your organization has less control over customization or internal improvement. Integrating proprietary or open-source tooling via APIs is a step up in capabilities. You are working to connect systems but may still be reliant on external providers for updates or changes. Contributing to open-source projects increases both capabilities and autonomy. At this stage, your organization is actively shaping the tools it uses, and you’re likely interacting directly with the open-source community. The peak of capabilities and “doing” occurs when your team is actively maintaining open-source tooling. Here, the organization takes full ownership of development, support, and customization, gaining the highest level of control and expertise or even rewarding from a creative experience.

First Lesson: Publish and Embrace Criticism

Many organizations hesitate to release open-source software due to fear of criticism.
Don’t be afraid—release early and release often. You are more likely to attract early adopters than critics in the beginning.
Document and share your specific programming methodologies to benefit the wider community. Even if the methodology sounds silly or too simple, it can be a factor of attractiveness.

Second Lesson: Practice Vulnerability Handling

Leading the development of open-source tools means taking responsibility for managing vulnerabilities in your projects.
For a CSIRT, this experience is invaluable, putting you in the shoes of a software vendor.
With widely-used projects like MISP, vulnerability handling is critical.
We’ve learned challenges like release notifications, vulnerability ID assignments, and proper disclosure.
The next time you handle a security vulnerability disclosure for software, you can share common experiences or even the painful challenges faced in coordinated vulnerability disclosure.

Third Lesson: Open Source as a Facilitator for Partnerships

Nothing fosters collaboration better than a successful open-source project.
Open-source contribution models often eliminate the need for NDAs, confidentiality agreements, or IPR agreements.
In EU research projects, contributing to open-source projects provides clear outcomes and measurable Technology Readiness Levels (TRL).
Contributing to an open-source project within a larger initiative often provides clarity on deliverables and emphasizes the practical (“doint”), hands-on aspects of the work.

Fourth Lesson: Managing the Ruins of Software Dependencies

Building and maintaining long-term open-source projects helps to grow a community of users and contributors.
Over time, outdated or obsolete software dependencies accumulate, becoming part of the development process.
As an “archeologist” of software stacks, you must address the inherent security risks, much like any software vendor would.

What about the ruins quote?

“Some cities have fallen into ruin and some are built upon ruins, but others contain their own ruins while still growing.” Jeffrey Eugenides

Software and security are indeed built on top of ruins. There are different ways to acknowledge this fact. One option is to ignore it and let the city fall into disrepair. Another is to simply build on top of the existing ruins. But the most interesting and rewarding approach is to embrace the ruins and use them as a foundation for growth. Open source and software, in general, are full of such ruins, and that is precisely how growth happens.

Fifth Lesson: Open Source as a Standard Generator

Developing information security standards without open-source implementations often leads to more discussion than creating interoperable tools.
Tools and formats created from open-source projects can serve as strong foundations for standards.
The MISP standard was built on real-world implementations, rather than theoretical committees.
Don’t hesitate to draft IETF Internet-Drafts based on your open-source tools—this can be the start of practical open and freely-accessible standards.

Sixth Lesson: Learning from Threat Intelligence Collection

Developing open-source tools for intelligence collection provides insights into the challenges faced by threat intelligence vendors.
Managing collection mechanisms allows your CSIRT to assess intelligence quality and understand fluctuations over time.
Building autonomy in intelligence collection often provides more value than relying solely on purchased vendor feeds.
Although threat intelligence collection may initially seem time-consuming, the experience gained enables your organization to become more agile in building accurate intelligence from new collections.

Seventh Lesson: Embrace Failure

Failure is an essential part of designing new open-source tools for CSIRTs.
The vulnerability management landscape evolves constantly, requiring adaptable tools.
We initially developed and maintained cve-search but faced challenges with cve-portal due to a lack of proper software identifiers, leading us to develop vulnerability-lookup.
Each failure is necessary to create innovative open-source software that solves real-world problems.

Eighth Lesson: Licenses and Copyright Are Critical

Don’t underestimate the importance of open-source software licenses.
Pay attention to Contributor License Agreements (CLAs) and who ultimately owns the code.
After experiencing open-source dependencies becoming proprietary, we have taken a strong stance against CLAs and favor multiple copyright ownerships.

Learn more about CLA-free initiatives

Ninth Lesson: Open Source as a Tool for Staff Retention and Skill Development

The cybersecurity field often faces a skills shortage, with high turnover due to intellectual fatigue.
Enhancing CSIRT capabilities through open-source projects helps retain talent and expand expertise.
Open-source projects promote staff autonomy, benefiting both individual team members and the organization as a whole.
Being part of an open-source project allows team members to feel individually recognized, which is a key factor in staff retention.

Conclusion

The open-source journey for a CSIRT team is challenging but rewarding. It pushes back against the status quo, enhances team capabilities, and allows for a focus on developing staff instead of acquiring products. By continuously contributing to and maintaining open-source projects, organizations can significantly boost their capabilities.

Additional Notes

Does this apply to other teams or organizations besides CSIRTs?

Most likely, these experiences have been shared by various teams, and some of the lessons may also apply to your organization, team, or project. Feel free to adapt and use any of these ideas.

Acknowledgement

Thanks to my teammates and colleagues at CIRCL for the discussions and work on this topic over the past 14 years. A special shoutout to Jean-Louis for the insightful conversations around Turn the Ship Around. This presentation was first given at the CERT-EU Conference 2024. Many thanks to the CERT-EU team, and especially to Saâd Kadhi, for the opportunity and support.

Alexandre Dulaunoy - adulau - Home Page

Don’t Do Team Meetings

Don’t Do Team Meetings

The problem with “what did you do last week?” meetings

They happen too late

They expose a communication issue

They are often boring

They scale badly

A better model: continuous sharing

Communication becomes timely

Communication becomes contextual

Communication becomes inclusive without being interruptive

Communication becomes searchable and durable

Meetings should be the exception

Conclusion

Bring Back RSS for Operational Security

Bring Back RSS for Operational Security

RSS was built for exactly this problem

Security operations need boring technology

It is simple

It is machine-readable

It is decentralized

It is automatable

It is auditable

Analyst fatigue is real, and RSS helps reduce it

RSS is already useful in vulnerability management

RSS is also a strong fit for threat intelligence collection

RSS works well as an operational building block

Feed -> filter -> dashboard

Feed -> transform -> alert

Feed -> enrich -> MISP

Feed -> merge -> publish

Feed -> archive -> search

We should stop confusing “old” with “obsolete”

Practical use cases for operational security teams

Vendor advisory monitoring

CERT and CSIRT awareness

Research monitoring

Threat actor visibility

Internal SOC dashboarding

MISP enrichment workflows

Executive or sector digests

The tooling barrier is very low

RSS supports open security ecosystems

What the security community should do next

If you produce information

If you build tools

If you run a SOC or CSIRT

If you maintain intelligence-sharing platforms

RSS is not dead. We just stopped using it enough.

Footnotes

Open Contributions Descriptor — or how to map your contribution in open source, open data, and open standards

Open Contributions Descriptor — or how to map your contribution in open source, open data, and open standards

Where the idea started

The problem: visibility in a fragmented open ecosystem

A recurring realization at FOSDEM

Beyond open source: a shared challenge

The hidden structural problem: centralized directories

The idea: describe contributions as first class metadata

A standardized discovery location

Decentralized discovery by design

Design principles

Domain agnostic openness

Human readable first

Machine readable by design

Lightweight adoption

Independence and sovereignty

What the Open Contributions Descriptor enables

Mapping the open ecosystem

Easier onboarding for contributors

Transparency and recognition

Machine discoverable catalogues, plural not singular

A simple mental model

Example use cases

Open source project

Open data platform

Open standards working group

Why a standard matters

Open by design

What comes next