How to secure a SaaS application?

You've probably lived this. Your CI/CD pipeline is green, no incidents overnight, your SDLC has been tooled for years. And yet, somewhere in the company, a product team opened an API for a partner without telling security. A demo environment set up for a prospect three weeks ago is still live. An intern created a test subdomain last year, and nobody remembers it. These are mundane situations, ones most software vendors live through, and none of them is a code flaw: it's your real attack surface, and it changes without you being told.

A software-as-a-service model sells continuous access to sensitive data, updated several times a week. Your application security therefore can't be limited to an annual audit. Between two checks, security flaws or unauthorized access can creep in, for lack of rigorously implemented security practices day to day. Your clients already audit you, and NIS2, DORA, and the Cyber Resilience Act are turning this gap into a regulatory compliance obligation.

In brief

• Code security (SAST, SCA, DAST) doesn't cover what the organization actually exposes: demos, APIs, cloud configurations, forgotten subdomains.

• Your clients, NIS2, DORA, and above all the Cyber Resilience Act are turning data protection into an obligation of proof.

• Annual pentesting keeps pace with neither your release cadence nor these requirements. The answer is a continuous model combining EASM and hybrid pentesting.

• The approach changes with your scale: 10, 100, or 500 applications aren't managed the same way.

• A 90-day plan, vendor-agnostic, closes out this article.

For a software vendor, the product being sold is also, mechanically, its attack surface.

If an attacker exploits a flaw, the data of all your clients is potentially affected at once. A data breach isn't fixed with a patch: it damages the trust the SaaS model is built on.

Your clients audit you before signing: security questionnaires, pentest requirements, ISO 27001 or SOC 2 certifications. Proving a solid security posture has become a condition of sale. Your release cadence also outpaces your audit cadence: "elite" teams deploy multiple times a day (Google Cloud's 2024 Accelerate State of DevOps report), while an annual pentest photographs a product that will have gone through dozens of releases before the next audit.

This triple challenge (client data, contractual requirements, release cadence) raises a simple question: who, in your organization, is actually responsible for all of this?

This responsibility is often distributed without being made explicit. At a mature vendor, it looks like this:

• Developers fix code within their own scope.

• DevOps teams manage cloud configurations, IAM, and pipelines, which is often where accidental exposures originate.

• Product owners arbitrate between roadmap and remediation.

• The CISO governs: visibility, prioritization, proof of control.

• Leadership carries final accountability. Articles 20 and 32 of NIS2 make governing bodies personally responsible, with a risk of being barred from executive duties in the event of serious failure.

That distribution isn't enough if nobody knows exactly what the regulation actually requires.

Four sources of pressure stack up, from the most immediate to the most structural:

• Your clients, the fastest to bite: a single security questionnaire can hold up a signature.

• NIS2 and DORA, in cascade: if you sell to a bank or an essential entity, your client's compliance becomes your own specification.

• The Cyber Resilience Act (CRA), which targets vendors directly: security by design, regular patch updates, and notification to ENISA within 24 hours of actively exploited flaws. Timeline: entered into force December 10, 2024, reporting obligations from September 11, 2026, full compliance by December 11, 2027. Penalties of up to €15 million or 2.5% of global turnover.

• GDPR: Article 32 requires security measures to guarantee the security of personal data, with CNIL-type penalties of up to 4% of global turnover.

Faced with these obligations, you still need to know which tools you already have, and which ones you're missing.

No single tool covers the whole chain.

The first six rows belong to the SDLC. Their blind spots all converge on the same point: what's exposed without being declared. That's exactly what EASM and continuous pentesting cover.

A continuous protection approach comes down to six habits, from spotting assets to producing proof for auditors.

1. Map what's exposed. You can't protect what you can't see. For example, a product team opens an API for a partner on a Friday evening: without continuous mapping, it can stay invisible to security teams for months.

2. Detect with precision, not with volume. A standard scanner can generate thousands of alerts unrelated to any real risk. Better to filter before forwarding.

3. Validate exploitability before acting. A theoretical vulnerability isn't a risk until it's proven exploitable. Hybrid pentesting combines automation with human expertise on complex scenarios.

4. Prioritize by real risk. Cross-referencing exposure, exploitability, and business criticality gives a fairer priority than a theoretical CVSS score.

5. Remediate fast, in the tools already in use. A finding that arrives by email ends up in an inbox, not in a sprint.

6. React within hours to emerging threats. When a critical CVE like CVE-2025-53770 (SharePoint, July 2025) drops, the question is whether it affects you, in near real time.

Taken together, these six habits let you spot an exposed asset the same day, rather than discovering it weeks later. They still need to be adapted to the size of the organization: they aren't run the same way at a ten-application vendor and at a group managing five hundred.

The number of exposed applications and services changes the nature of the problem, not just its size.

• About ten applications. A one-off pentest seems sufficient, and that's the most deceptive stage: the undeclared surface already exists. The right move is to set up a first external view of what an attacker actually sees.

• About a hundred applications. Broad manual pentesting becomes impossible. EASM becomes the foundation, risk-based prioritization becomes mandatory.

• Five hundred applications and up. The issue is no longer tooling but governance: segmentation by entity, delegation to product teams, metrics for leadership.

What's exposed on the internet is tested constantly by automated attackers, unlike what stays internal. Applying the same policy to both is the classic mistake.

Patrowl is a French platform for continuous threat exposure management (CTEM): it secures what your organization actually exposes, where SAST, SCA, and DAST secure what you write.

Four things worth a closer look, without claiming to be unique on the market:

• Human qualification of findings: every result is verified before being sent.

• Application business logic testing: unauthorized access controls, tenant isolation.

• Flat-rate pricing per scope: no charge per vulnerability.

• Hosted in France (OVH Gravelines).

Four questions to ask yourself this week:

1. How many assets are exposed on the internet under your name today?

2. Of the vulnerabilities flagged last month, how many were actually exploitable?

3. How much time passed between a critical CVE's publication and the moment you knew whether you were affected?

4. Can you produce an attestation of continuous monitoring for the past 12 months?

Days 1 to 30: see. Consolidate the official inventory, get an independent external view starting from your domain name, ask product teams what's been created this quarter. Deliverable: an asset list sorted into known, forgotten, and unknown.

Days 31 to 60: filter. Apply manual filtering to a sample of vulnerabilities: how many concern actually exposed assets and are proven exploitable? Define a prioritization criterion with your development teams.

Days 61 to 90: industrialize. Wire validated findings into your existing tools, and track three metrics: exposed assets, share covered by a recent test, remediation time on the critical-and-exposed. Beyond a hundred applications, this plan becomes hard to sustain without EASM tooling and continuous pentest capacity.

You did nothing wrong that morning. Your pipeline was green, and yet your real exposure had changed without you knowing it. That's the case for most software vendors: a gap grows between what the SDLC controls and what the company actually exposes, one that regulation is turning into a compliance obligation. Protecting what you build no longer happens in an annual audit, but in your ability to see, validate, prioritize, and prove, continuously.

The opening scenario (CI/CD dashboard, open API, exposed bucket) is a composite illustration, not a named client case.

Verified external sources

• 2024 Accelerate State of DevOps Report, Google Cloud, October 2024.

• Directive (EU) 2022/2555 (NIS2), Articles 20 and 32. References: cyber.gouv.fr, EUR-Lex.

• Regulation (EU) 2024/2847 (Cyber Resilience Act), entered into force December 10, 2024. Official FAQ: cyber.gouv.fr, digital-strategy.ec.europa.eu

• Regulation (EU) 2016/679 (GDPR), Article 32.

• Regulation (EU) 2022/2554 (DORA).

• CVE-2025-53770, critical SharePoint vulnerability ("ToolShell"), documented by Microsoft Security Response Center and CISA, July 2025.

Internal Patrowl data, to confirm before publishing

Patrowl client experience, to be validated before going live: share of unknown assets during onboarding, false positive rate on a standard scanner, MTTR reduction for a cited client, alert delay for clients affected by CVE-2025-53770.