What is a signed-in web application assessment?
A scan that only sees your sign-in page has not tested your application. A web assessment signs in first, with an account you save on a CI/CD pipeline, then crawls and tests what that account can reach.
It runs as part of the pipeline's scan, so its findings count toward the same gate that passes or fails your CI job. If the scan was set up to sign in and did not sign in, the gate fails whatever it found.
| Question | Short answer |
|---|---|
| What it tests | The running web application, signed in as the account you save. |
| How it signs in | A sign-in form, or a sign-in that takes a JSON body. |
| Where it runs | As part of a CI/CD pipeline scan, from PentestOps or through a PentestOps agent inside your network. |
| What it sends | What your testing mode allows: Off, Passive or Active. |
| What the result says | Whether it signed in, what it crawled and tested, and what it left alone on purpose. |
| Which plan | Included in the Enterprise plan. |
How the crawl reaches your application
The crawl starts from the start URLs you give, which must be on the pipeline's own target, and follows the links it finds inside it.
On a PentestOps agent that has a browser, the crawl drives your application in that browser and runs its JavaScript. It reaches pages that only appear once a script has run, and it records the calls your pages make to your APIs, so those calls are tested too without an OpenAPI or Swagger file.
When PentestOps runs the scan from outside your network, or on an agent without a browser, the crawl reads the pages without running their JavaScript and sees what the markup links to.
What it tests
You choose the testing mode on each pipeline. Off still crawls, so the crawl's requests are still sent, and reports nothing. Passive reports what it sees in the pages and responses the crawl fetched. Active also sends attack payloads to the inputs it found, testing for faults such as injection and cross-site scripting.
Inputs are tested where your application takes them: query strings, form bodies, JSON and XML bodies, and, when you choose, cookies, headers and path segments.
Built to be safe on a live application
Active mode sends attack payloads and can submit forms, so point the sign-in at a test or staging copy of the application where you can. These limits hold on every assessment.
- A Never test list. Paths such as sign out, delete, reset, cancel, change password, checkout, pay, upload and invite are never touched. You can add your own paths, and your additions never replace the list.
- Parameters it never fills in. Password, token, one time code, PIN and card security code fields, and the sign-in form's own fields, are never filled in or replayed.
- Forms stay unsubmitted unless you ask. Once a sign-in is saved, Submit forms is off by default, so the crawl does not act as your account unless you turn it on.
- Requests that delete or overwrite are held back. They are left out of testing unless you allow them.
- A refused sign-in pauses the pipeline. A sign-in your application refuses is reported, and the pipeline's next run is not started until the password is entered again, so a wrong password does not lock the account.
Your saved sign-in
Use an account made for scanning, with the fewest rights that reach the pages you want tested. The scan cannot answer a second factor, so switch it off for that one account.
The password is stored encrypted by PentestOps until you remove it or revoke the pipeline. It is never shown again, and it is used only against the pipeline's own target. Revoking the pipeline, or archiving its asset, wipes it. Every change to the sign-in is recorded in the pipeline's history, with who made it and when, never the value.
Reading the result
Two things are reported. The gate verdict in your CI job says whether the findings at or above your threshold stopped the pipeline. The assessment's own state, on the Web Assessment page and in the report, says how far it got.
Beside the state is one sentence the assessment wrote about its own run: whether it signed in, how much it crawled and tested, and what it left alone. Under it, a Not covered by design list names what it deliberately did not touch, so you know where to look by hand.
| State | What it means |
|---|---|
| Completed | It ran to the end of what it was asked to do. |
| Partial | It ran and did not cover everything. What it did find still counts. |
| Failed | It started and could not reach any site it was to assess. |
| Not run | It did not run, for example because its settings could not be used. |
| Not applicable | The scan found no web site on the target to assess. |
Applications inside your network
A pre-production application inside your network is assessed through a PentestOps agent installed there, when the target is an IP address, a network range or a domain name and the agent is online.
A URL or an API target cannot run as internal. If your target is one of those, the assessment runs from PentestOps and needs the application to be reachable from outside.
What a signed-in web assessment does not do
- It does not sign in through single sign-on, and it cannot answer a second factor. It posts a sign-in form or a JSON body to a sign-in page on the target.
- It does not test more than one role. One account is tested per pipeline.
- It does not report faults that only show up somewhere else, such as a payload that lands in an administrator's screen, a log viewer or an email.
- It does not clean up test records that submitted forms create.
- It does not block pull requests or merges on its own.
- It does not comment on pull requests or merge requests.
- It does not publish SARIF or send results to GitHub code scanning.
- It does not scan your source code, dependencies, containers or infrastructure as code. It tests the running application.
- It is not an IDE plugin.
- It does not scan each commit or each diff.
- It is not zero configuration.
- It does not hook your repositories, Git events or deploys, so it does not scan automatically on every deploy.
Where it sits in your plan
Signed-in web application assessment is included in the Enterprise plan, and it runs on a CI/CD pipeline, which is also included in the Enterprise plan. Current plan detail is on the pricing page, and you can talk to sales about Enterprise scope.