From scoping to safe-to-host certificate

What the certificate says

A safe-to-host certificate states that a specific build of a web application was audited by a CERT-In empanelled organisation and that, at the end of the audit, no open vulnerabilities remained within the agreed scope. Hosting providers for government and public sector sites commonly ask for one before they will deploy an application.

The certificate does not say the application is secure forever. It describes one build, tested against a defined methodology at a point in time. Understanding that limit is the key to planning the work.

It also helps to know what the certificate is not. It is not an ISO certification, and it does not cover the hosting infrastructure, which the hosting provider secures and audits separately.

Scoping

Scoping fixes what will be audited. We ask for the application URL on staging, the intended production URL or hosting path, a list of modules and user roles, any APIs the front end depends on and the technology stack.

Applications with many roles, file uploads, payment flows or integrations with other systems take longer, because each adds attack surface. Agree the scope in writing, including anything excluded, before testing begins.

Tell us early about any deadline set by the hosting provider or the department that owns the application. A realistic plan allows for at least one round of fixes and a re-test, and most delays come from the fixing stage rather than the testing.

• Staging URL and intended production URL or hosting path.
• Modules, user roles and test accounts.
• APIs and third-party integrations.
• Technology stack and framework versions.

Auditing the staging build

Testing is done on a staging environment that runs the build you intend to host, configured as it will be in production. The audit team tests against recognised application security categories, such as injection, broken access control, authentication weaknesses, security misconfiguration and insecure handling of data.

Testing combines automated scanning with manual work. Access control and business logic flaws, such as one user reading another user's records by changing an identifier, are rarely found by scanners alone.

Configuration is tested as well as code. Error messages that reveal stack traces, missing security headers, default credentials, directory listings and outdated libraries are common findings that are quick to fix if caught early.

• Provide test accounts for every role in scope.
• Freeze functional changes during testing so results stay valid.
• Use test data, not live personal data.
• Name a developer who can answer questions quickly.

Fixing findings

The first round produces a report with each finding, its severity, evidence and a recommended fix. Your developers fix the issues and produce a new build. Fix the cause rather than the symptom; blocking one payload at the edge while the underlying query stays unsafe will usually fail the re-test.

Keep a short change log against each finding. It speeds up the re-test and gives you a record if the same issue appears in a later release.

Prioritise by severity, but do not leave low-severity findings to the end. The certificate is issued only when every finding in scope is closed, so a long tail of minor issues delays it as much as one serious flaw.

Re-test until clean

The re-test checks each finding against the new build and also looks for regressions introduced by the fixes. Some applications close everything in one round; others need more. The certificate is issued only when no vulnerabilities in scope remain open.

Give the audit team the new build on the same staging environment, with a list of what changed against each finding. If unrelated features were added at the same time, say so; new code is new attack surface and may need testing too.

Hash value of the audited build

Once the final build passes, a cryptographic hash is calculated over the audited code or deployment package and recorded on the certificate. A hash is a fixed-length fingerprint: changing even one byte of the input produces a completely different value.

The hosting provider can calculate the hash of what it is about to deploy and compare it with the certificate. If they match, the deployed code is the code that was audited. If they do not, the certificate does not cover what is being hosted.

The hash is only useful if it is calculated the same way each time. We agree with you which files or package are hashed and which algorithm is used, and record both so the hosting provider can reproduce the result.

Hosting path and validity

The certificate also records the URL or hosting path where the application will run. Deploy the audited build to that path without modification; even a configuration change made directly on the server can mean the deployed application no longer matches what was tested.

The validity period is stated on the certificate, and hosting providers may set their own expectations on top of it. Anyone can check the certificate in our public register through the QR code or at /validate.

If the hosting path changes, for example to a new domain or sub-path, contact us. The certificate may need to be reissued even if the code is unchanged.

Re-audit after changes

Any change to the code changes the hash, so the existing certificate no longer covers the new build. Plan releases with that in mind: batching changes into fewer, planned releases reduces the number of re-audits. A re-audit of a changed application is usually shorter than the first audit, because the scope can focus on what changed and on areas the change could affect.

Security patches to frameworks and libraries are changes too. Keep dependencies current, and plan a short re-audit when a patch is needed rather than delaying the patch to protect the certificate.