Railway, PHP, CRA: when AI turns security monitoring into a decision

A critical vulnerability has just been published. Being informed is one thing. Knowing whether our own systems are exposed is another.

This week, two alerts were a reminder of how much our architectures depend on components and services we don’t fully control.

On one side, Railway announced a compromise of some of its internal systems, with potential exposure of customer secrets.

On the other, PHP released fixes for critical vulnerabilities that could allow remote code execution.

Two different situations, but one common question: what are the possible impacts on the systems we are responsible for?

Security begins well before the alert #

For over a year, I have chosen to apply to my projects a quality and risk-analysis approach inspired by the Cyber Resilience Act (CRA), even when they are not necessarily subject to that regulation.

Documented architectures, identified dependencies, risk analyses, control measures and traceability of decisions are part of the way I design a system.

This work is an investment.

But it means not starting from scratch when an incident occurs.

When documentation becomes operational #

I have gradually integrated this knowledge into RAG and GraphRAG databases, accessible to ELARA, my professional AI assistant.

ELARA monitors various security channels and cross-references alerts with the technical and quality information of my projects.

It can thus identify the projects potentially concerned, the technologies involved, the associated risks and the actions to consider, across three severity levels.

These levels aren’t arbitrary judgements by the AI: they rest on the analyses and criteria I defined beforehand.

The AI performs the cross-referencing of information. The evaluation framework comes from engineering.

Railway: the value of having anticipated #

I wasn’t directly affected by the Railway compromise.

But when the alert appeared, I was able to check my situation very quickly thanks to the already-structured knowledge of my projects.

That is precisely what I was looking for.

Not to discover your architecture at the very moment you have to make a decision.

And above all, not to confuse the absence of an alert with proof of the absence of risk.

AI amplifies a method, it doesn’t replace it #

A RAG doesn’t guarantee the accuracy of an analysis. A GraphRAG doesn’t guarantee the exhaustiveness of the dependencies.

The relevance of the result depends in particular on the quality, the timeliness and the traceability of the information available.

AI can speed up the cross-referencing, surface risks and prepare actions.

But the decision remains tied to the reality of the architecture, to the possible consequences and to the acceptable level of uncertainty.

In the end, what interests me in this approach isn’t only automating security monitoring.

It is making usable, at the moment it becomes necessary, all the knowledge accumulated during the design of a system.

AI didn’t let me improvise faster. It let me exploit faster what I had anticipated.

And that is perhaps where a large part of its value in engineering lies.