# Discovery, verification and security assurance are three different things

> What behavioral discovery establishes, what verification adds, and why neither is a security audit or a compliance result.

Published 2026-10-24 by Maxint. Written for: Security and architecture, Engineering leaders.
Canonical: https://foundry.maxint.com/resources/discovery-verification-and-security-assurance

Three activities get mixed together whenever a team studies a system before changing it or connecting something to it. They answer different questions, use different methods and support different decisions. Treating one as a substitute for another is how a team ends up confident about the wrong thing.

- **Discovery** answers: what does this system do, expose and depend on?
- **Verification** answers: which of those findings hold up under a repeatable test?
- **Security assurance** answers: does this system resist an adversary, and does it meet a defined standard?

A report can be excellent at the first two and say nothing about the third. That is not a flaw in the report. It is a boundary, and it should be written down.

## Discovery: establishing what is there

Discovery produces an inventory. For an HTTP service, that means routes, methods, parameters, response shapes, status codes, authentication requirements and the other systems it calls. For a batch job, it means inputs, outputs, schedule, side effects and what happens on partial failure.

Discovery findings come in two strengths, and a good report keeps them apart.

- **Observed.** Seen directly. The service returned `409 Conflict` when the same `Idempotency-Key` header was sent twice within an hour. A connection was opened to `ledger-db` on port 5432 during order creation.
- **Inferred.** Reasoned from evidence, not yet exercised. The retry window is probably one hour, because the second request succeeded after 61 minutes in a log sample. The `legacy_flag` column is probably unused, because no code path reads it.

Inference is useful. It tells you where to test next. It is not a finding you can build on without a test, and it should never be rewritten as an observation in a summary.

Discovery also has a scope. It covers the environments, inputs and time window you had access to. A route that only activates under a feature flag you never set, or a code path that only runs on the last day of the quarter, is **open** until someone exercises it.

## Verification: turning findings into evidence

Verification takes a discovery finding and makes it repeatable. A finding is **verified** when a test exists that fails if the behavior changes.

```yaml
finding: duplicate submissions within 1h return 409
state: verified
test: conformance/orders/idempotency.spec.ts
runs_against: staging, 2026-10-21
```

Three things change once a finding is verified:

1. It can be re-checked after every deployment, so you learn when the behavior moves.
2. It can be handed to another team as a contract rather than a description.
3. Its limits are explicit. The test above says nothing about a 25-hour gap, a different tenant or a different region. If those matter, they need their own tests.

Verification does not make a system correct. It confirms that it behaves as the finding says, under the conditions tested. A system can be fully verified and still do something the business never wanted. That is why behavior reports record what a system does, not whether it should.

## Security assurance: a different question entirely

Security assurance asks whether a system withstands deliberate misuse and whether it meets a defined bar. The methods are different: threat modeling, penetration testing, code review against a vulnerability class, configuration review, control testing against a framework, and the governance around all of it.

Behavioral analysis is not a security audit. It does not make a system secure. A behavior report can tell you that an endpoint accepts a `role` field and that the field is observed to change the response. It cannot tell you whether an attacker can set that field, whether the authorization check behind it is complete, or whether the dependency that handles it has a known vulnerability. Those are security findings, produced by security methods, owned by people accountable for them.

Discovery feeds security work. An accurate inventory of what a system exposes is the starting point for a threat model, and a verified behavior is a stable thing to test against. But feeding a process is not the same as completing it.

Two claims should never follow from an analysis report:

- "The system is secure because its behavior has been mapped." Mapping shows what is there. It says nothing about what an adversary can do with it.
- "Running the analysis privately makes us compliant." Private deployment controls where data goes. Compliance depends on how the organization operates, what it logs, who has access, how long data is kept and whether an assessor can see all of it. Deployment location is one input among many.

## Where the three meet

| Question | Discovery | Verification | Security assurance |
| --- | --- | --- | --- |
| What endpoints exist? | Yes | | |
| Does `POST /refunds` reject amounts above the original charge? | Observed or inferred | Verified by test | |
| Can a tenant refund another tenant's charge? | Might surface an observation | Can test a specific case | Owns the answer |
| Are we meeting our control framework? | | | Owns the answer |

The useful pattern is sequential. Discover what is there. Verify the behaviors you intend to rely on. Hand the verified inventory to security and compliance work as an input, with the open items listed, so that work starts from evidence instead of from the original documentation.

## What to ask for in any report

Before accepting a report about a system you are about to protect, extend or connect, check for four things.

1. Every finding carries a state: observed, inferred, verified or open.
2. Verified findings name the test and the environment it ran against.
3. The scope section says which environments, inputs, flags and time windows were covered.
4. The limitations section states what the analysis is not. If it does not say "this is not a security assessment" in plain words, ask why.

A report that meets this bar is more useful to a security team than one that implies more than it can support, because the security team knows exactly where to start.

## Where Foundry fits

Foundry does discovery and verification. It delivers a behavior report in which every finding is labeled observed, inferred, verified or open, together with a dependency map, interface specifications and the test suite behind each verified finding. It does not certify security, and its reports say so. The [approach page](/approach) sets out the method and its limits in full.