A security audit that rechecks what's been fixed and who sees what

First of all: ADRI only audits what's yours or what's authorised. Before launching an active audit against a website, it asks you for an explicit yes in the chat with a declaration: that you own that target or that you have written authorisation from its owner. The request and your answer are recorded. By default, management, administration and the super-administrator can request audits, and every request, including denied ones, is kept on the scan audit screen.

What is a vulnerability retest?

It means testing a flaw again after someone says they've fixed it. It sounds obvious, but this is where things go wrong most often: the patch was applied on one server and not on another, one route was fixed and the one next to it is still the same, or a later update reopened it.

With ADRI, a «re-test» is as simple as asking for another audit of the same target. The difference is that it now remembers what was decided about each finding.

Each finding has its own record and its own status

Each finding gets a stable identifier, of the type H-1a2b3c4d, which stays the same from one audit to the next. And it goes through these states:

• Suspected. The scan found it and it isn't confirmed yet.
• Verified. There's proof that it's real: ADRI records it with its note, or the scan itself proved it.
• Fixed. A person says so, with the finding identifier in their message. ADRI can't mark it as fixed on its own.
• Closed. In the next audit it no longer appears and the test that detected it ran properly.
• Reopened. You marked it as fixed and it still shows up.

There are also two decisions that only a person can make: false positive (it isn't a real problem) and accepted (it is real, but you take on the risk). Both are left with their note.

When can a vulnerability be considered closed?

Only when the new test proves it. The rules are strict on purpose:

• If the test that was supposed to detect it never ran or failed, the re-test is marked as inconclusive, and it tells you so. Nothing gets closed just because nobody looked at it.
• If an open finding simply doesn't appear, it doesn't close itself: it may be that this part wasn't checked that time.
• If something that was closed appears again, it's marked as a regression, which is exactly what's most important to see.

The summary of these changes goes at the top of the report: what was closed, what was reopened and what came back.

What is a role-based access matrix?

Many serious flaws can't be seen from the outside. An anonymous scan doesn't detect that an employee can open someone else's record, or that a portal customer sees invoices that aren't theirs. That's what the role-based access matrix is for.

It works like this: you declare your application's roles in a file, with test accounts from your test environment, and which roles should be able to see each route. ADRI prepares the starting template for you if you give it the code. Then it requests each route with each role and compares:

• 🔴 Improper access: a role that shouldn't be able to see the route, does.
• ⚠️ Unexpected block: a role that should be able to see it, can't.
• ❔ Indeterminate: a server error or an ambiguous response that has to be looked at by hand.

To avoid causing damage, it only performs reads, doesn't follow redirects, doesn't leave the domain you gave it and has a cap on routes and roles, with pauses between requests. The report shows neither the page content nor the test cookies: only the status, the size and a fingerprint for comparison. You provide the test accounts; ADRI doesn't invent them or ask you for them over chat.

If you have the code, the audit points to the line

If you give it the path to your application's code, ADRI first builds a static map: which routes exist, which ones require a login and which ones reach sensitive operations. By cross-referencing it with the scan, a finding confirmed by code comes out with its cause: the file and the line. What the code hints at but the scan didn't touch stays as a lead, never as a finding.

It diagnoses, it doesn't repair

The audit points things out and prioritises them; it doesn't apply patches on its own. If something in the code needs fixing, ADRI prepares it and it's done with your approval. Then another audit closes the loop.

More in security and compliance and in automated pentesting with AI agents. If you're interested in how ADRI asks for permission before acting, we explain it in when ADRI asks for your permission, or request a demo.

Frequently asked questions

• Security
• Audit
• Roles
• ADRI