Is Raisetalk secure? What we measure, fix and publish

A clean baseline yesterday is no longer clean today

Software does not decay because you touch it. It decays because the world around it moves. You have not changed a line of code in three weeks, and yet your product may be vulnerable this morning: a CVE has just been published for a transitive dependency you never explicitly chose, your container base image ships a system library that has just reached end of life, a vendor-supplied binary embeds a version of a third-party library frozen at compile time, a cloud setting considered acceptable a year ago has become a documented bad practice.

Vulnerability disclosures now run at more than a hundred a day across all vendors. At that pace, the relevant question when assessing a supplier is not "are you certified?". It is: what happens at your company between the moment a vulnerability is published and the moment it is fixed? How long it takes, through what mechanism, with what evidence, and who decides that it is fixed.

That question concerns us more than most. Raisetalk processes call recordings, transcripts and personal data belonging to end customers who have never heard of us: they simply called their bank, their insurer or their energy supplier. The trust placed in us is delegated trust, and that kind of trust is demonstrated rather than declared.

So this article describes the machinery, not the intention. What we measure, how often, what happens when an alert fires, what we publish, and finally how this approach compares with the two other classic answers on the market: certification and penetration testing.

What we analyse, continuously

We rely on Aikido Security as our analysis and protection platform. The reason for that choice is simple: coverage. Many tools do one thing very well, whether static code analysis or cloud posture management. The problem is that an attacker does not pick an entry point according to how your tooling is divided up. An API key left in a configuration file, a CVE in a system package inside a container image and an over-broad IAM role on a service account are perfectly equivalent from their point of view.

Six surfaces are therefore monitored, continuously.

That last point deserves a note, because it is rarely done. A scanner that stops at the login page only analyses the shop window. So we gave the scanner authenticated access to the API, so that it also explores what sits behind authentication, where the routes that actually handle data live. It is less comfortable, since it mechanically produces more findings. That is precisely why it is useful.

What protects the code while it runs

Analysing means finding what could be exploited. Protecting means stopping what is being exploited. Neither replaces the other, and we use two distinct components for the second half of the job.

An application firewall embedded in the API. Zen does not run in front of the application like a classic WAF placed at the edge: it runs inside the application process, which gives it access to context the edge does not have. It does not merely see a suspicious string in an HTTP request, it sees the SQL query actually built, the command actually executed, the file path actually opened. It can therefore tell a string that looks like an injection from a string that genuinely produces one. On our side it has been running in blocking mode since autumn 2025, not in observation mode: a detected attempt is interrupted, not just logged.

That decision has a cost, and it should be stated: a firewall in blocking mode can, in theory, interrupt a legitimate request. We accept that, and it is also why version upgrades of this component are handled with the same caution as a functional change, checking what they alter in blocking decisions before deploying them.

Posture checks on workstations. The second component covers our own machines, the ones we develop and administer production from. Disk encryption, session locking, system updates, active antivirus: these controls are verified continuously on every workstation. This is not decorative compliance. A flawless platform administered from an unencrypted laptop left open on a train is still a vulnerable platform, and an attacker targeting a software vendor rarely starts with the product.

What happens when an alert fires

This is where the difference lies between a purchased analysis platform and a real security practice. A tool that raises two hundred alerts produces two hundred alerts. It does not produce security. Security starts at the next step, the one nobody demonstrates in a sales meeting.

Our process is written down and followed every time, in the same order.

1. Grouping by root cause. A group of thirty-six findings is almost never thirty-six problems. It is often a single line in a dependency lock file, projected onto three container images and two repositories. The first step is therefore to separate the single root cause from the affected surfaces, and to state how many distinct fixes are genuinely needed. That is what keeps alert volume from being mistaken for workload, and prevents thirty-six symptoms being treated as urgent instead of one problem.

2. Opening a ticket, with its deadline. Every group handled produces a ticket in the relevant repository, with its severity and its remediation deadline. Nothing lives in a dashboard alone: what has no ticket has no owner, and what has no deadline has no priority.

3. Verification in our own code. This is the step the scanner cannot do for us. A CVE announced on a library does not tell you whether the vulnerable code is reachable from yours. We go and read the files concerned, confirm the version actually installed, the constraint actually declared, and the real callers. An SSRF vulnerability in a function we never call does not carry the same urgency as a deserialisation flaw reachable from a public route. This verification sometimes produces the opposite conclusion to the alert: false positive, dead code, or a fix already in place. In that case the decision is recorded with its rationale, never through a silent dismissal.

4. The fix, and everything that goes with it. A remediation plan does not stop at a version bump. It explicitly includes the steps outside the code: rebuilding the image, rotating a secret, rewriting history if a credential has been exposed, restarting the service concerned. A secret removed from source code but still valid at the provider is not a fixed secret.

5. Post-deployment verification, then closure by a human. We check that the fix is actually present in what is running, and not only in what has been committed. An image rebuilt but not deployed, traffic left pinned to the previous revision after a rollback: these gaps are classic, and they turn a fix into the illusion of a fix. Only then does a human being close the ticket.

The hardening baseline, in detail

Detection machinery is only worth as much as the foundation it applies to. Here, without being exhaustive, are the principles that govern the Raisetalk infrastructure today. They are not declarative: each one is verified continuously by the analyses described above, and any deviation becomes an alert.

• No container runs with administrator privileges. Master processes as well as worker processes run under an unprivileged account, and services listen on unprivileged ports.
• Images contain no SUID binaries, and a check fails the image build if one appears. An installation step added later could reintroduce one with nothing to flag it: hardening that does not monitor itself is always lost at the next update.
• Secure boot is enabled on virtual machines, so that the boot chain is verified before the system loads.
• Administrative access goes through identity, never through a shared key. Authentication via the cloud identity, project SSH keys blocked, access to machines through an authenticated tunnel rather than an exposed administration port.
• Each service runs under a dedicated account, limited to the rights it genuinely needs, and never under a default account: those carry, by construction, far too broad a set of roles.
• The database itself enforces encrypted connections, rather than leaving that to the goodwill of whichever client connects to it.
• The public site applies a strict content security policy, to the point of forbidding inline styles: a real constraint for whoever writes the components, and one injection surface fewer.

None of these points is spectacular in isolation. It is their combination, and above all the fact that they are verified permanently rather than once at installation time, that constitutes the real work.

Where we stand, as of 19 August 2026

At the date this article is published, the dashboard shows no open alert across the entire perimeter. The compliance reports generated by the platform give the following results.

The platform also places Raisetalk among the 5% most secure applications in its estate. That is a relative comparison supplied by a third party, and we quote it as such.

Transparency: the report, on request

A supplier who tells you everything is fine is asking you to take their word for it. We would rather let you look.

The badge in the footer of every page on this site opens a form to request access to the security audit report. The report is generated from the real state of the platform at the time of the request, not from a fixed document written once and for all: it comes from the same source that produces the figures above.

Why on request rather than in open access? Because a security report describes a technical perimeter, and knowing who it is shared with is part of basic hygiene. The form is short and requests are handled quickly.

It is also, for us, a one-way commitment. Publishing a badge that opens access to an independent measure of our security state means accepting in advance that a bad month will be visible. That is precisely what makes the information worth something the rest of the time.

The other approaches, and why they come afterwards

Two answers dominate the market when a buyer raises the security question. Both are legitimate, and both are insufficient on their own. Our position comes down to one word: order.

ISO 27001 certification

ISO/IEC 27001 certifies an information security management system. An accredited body verifies that you have identified your risks, defined controls, documented your procedures, and that you keep the whole thing alive. The certificate is valid for three years, with annual surveillance audits. It is serious work, it structures an organisation durably, and it is a strong signal for a buyer.

Its limits follow from its very nature, and there is nothing polemical about them. The audit proceeds by sampling, on a given date. It validates a management system, not the technical state of your product at the moment your prospect reads the certificate. Nothing in a certificate obtained in March tells you anything about the critical vulnerability published in October in one of the application's dependencies. The certificate attests that the organisation has a process to deal with it, which is very different from attesting that it has dealt with it.

It is a photograph, taken by a professional, with an excellent camera. It remains a photograph.

Penetration testing (pentest)

A penetration test brings what no scanner can produce: the intelligence of a human attacker. Chaining three individually minor weaknesses to obtain access that should not exist, subverting business logic that is perfectly compliant with the code, reaching another customer's object by manipulating an identifier: none of that is detected by pattern analysis.

Its limit, however, is budgetary, and it is structural. You buy a number of days, so you define a scope. Anything outside that scope is not tested, and the report will often not say so, or only in very small print... It will describe what was found where the search took place. Like certification, the test holds for a date, a version and above all a limited scope. Next month's deployment invalidates part of it.

The three approaches, side by side

These three columns do not replace one another. They complement one another, in that order. Getting certified without continuous monitoring means neatly documenting a process you cannot execute. Commissioning a penetration test on a perimeter where known vulnerable dependencies are still lying around means paying expert rates to discover what a scanner finds for free overnight. And commissioning it on a narrow scope, chosen precisely because you already have it under control, means buying good news rather than information: the news is decided when the scope is drafted, not when the test is run. A useful penetration test is one whose scope was chosen for its difficulty, and whose extent is disclosed alongside the conclusion.

Our sequence is therefore this one: first permanent measurement and systematic remediation, because that is what actually protects our customers' data today. An ISO 27001 certification is under consideration for the future, and an external penetration test is on our roadmap: they will come to validate and complete existing foundations, not to replace them or stand in for them.

What continuous monitoring does not replace

It would be dishonest to close without saying where what we describe here stops.

An analysis platform does not know your business. It knows that an SQL query is built by concatenation. It does not know that a user in one team must never see another team's evaluations. Those rules are specific to our product, and no vulnerability database contains them. That is why we maintain our own threat model internally: deployment units, entry surfaces, trust boundaries, and the business rules that must never give way. It is reviewed and updated like code, and it serves as the map when we look for what no tool will look for on our behalf.

A compliance score is not a guarantee. It indicates that no known problem remains over the observed perimeter. That is worth having, and it says nothing about vulnerabilities that are not yet public. Nobody can promise otherwise, and anyone who does should be treated with caution.

Security remains a chain. It includes our subcontractors, our AI model providers, the hosting platform, and the way your own teams use the product. That is precisely why access control by roles and scopes and the pseudonymisation of personal data belong to the same subject as vulnerabilities: they determine what stays protected on the day something gives way elsewhere.

The last word

We could have written a short article: "zero vulnerabilities, thirteen frameworks, top 5%". It would have been accurate, and it would have proved nothing. The figures that matter in security are not the ones you display, they are the ones you can explain: where they come from, what they cover, what they leave out, and what happens on the day they deteriorate.

The security of a piece of software is not a state, it is a tempo. It is not proved by an annual document, but by the ability to handle, week after week, whatever the measurement surfaces, including when that is uncomfortable, including when it forces you to rebuild a machine or rework a component that was working perfectly well.

And because a supplier's assertion is never worth as much as a buyer's verification: the report is at the bottom of this page.

Check for yourself

• Request the security audit report: open the form, or click the badge in the footer.
• Our answers on data and the GDPR: the frequently asked questions
• Ask us a specific question: www.raisetalk.com/en/contact

The figures quoted in this article correspond to the state observed on 19 August 2026. They change: that is precisely the point. A security dashboard that has not moved in six months is not the sign of a stable product, it is the sign of a measurement that has stopped. So the right question to ask a supplier, ours included, is not "is your score good today". It is "what happens at your company on the day it is not".