Security

“AI-generated code is insecure” is the standard objection to building an app this way, and the honest answer is not a promise — it is something you can look at. The Security area of Checkup is that: the project’s current posture, in rows written for the person who owns the app rather than for a security engineer.

It appears in your project from the Build stage.

What the area shows

Three groups, each a short list of statuses:

• Scans — the deterministic security checks: dependencies with known vulnerabilities, and credentials accidentally committed to the repository. There is no separate scan button: a checkup scans them every time it runs.
• Edge — how the deployed app is protected in front of the application: attack-traffic filtering, security headers, and request rate limits.
• Access — who can sign in and how, including multi-factor authentication.

What the security-focused AI pass of a checkup found in the code itself — missing authorization, unsafe handling of user input, and similar — is counted in a line at the top of the area, which takes you to those findings on the same page.

There is no grade and no score. A single number would be a claim the product cannot honestly make; a row that says what is true and whether it needs attention is one it can.

Some rows only apply from Rehearsal

Edge protection is about a deployed environment, so those rows read as “applies from Rehearsal” while the project is still in Build. That is expected, not a gap — there is nothing in front of the internet yet. Scheduled scans start at Rehearsal too; until then, each checkup scans dependencies and secrets.

When an Edge row needs attention

Once a server exists, the firewall and security headers rows check that its setup recorded them. They are part of setting a server up, and an ordinary publish skips setup once the server is there, so publishing again does not bring a missing one back. Use Repair server on the row: Publish opens on that server and asks to confirm. Repairing sets the server up again, keeping what already exists, and publishes the same release. The row turns green on the next checkup.

A row that says it couldn’t check means Sapilon could not read the server’s records just then. That is not a finding about your app; it clears on its own the next time the records can be read.

Security does not stop at the gate

The checks a checkup runs are a statement about a date. A dependency that was clean when you promoted can turn into a known vulnerability the following Tuesday, and a successful app can go untouched for months.

So scanning continues on its own for projects in Rehearsal and Live, on a schedule and whenever the underlying platform ships a release. When the vulnerable piece is part of the Sapilon platform, the fix arrives through a platform update rather than any work on your side. When it is in your own project’s code or dependencies, it shows up here as something to fix, with the Agent or an expert.

What this is not

It is not a compliance certification, and it is not penetration testing. Human offensive testing is expert work you can request; see expert work pricing.

Next: Checkup · Automated Tests · Rehearsal