01
Security Validation
Authorised discovery and testing of websites, applications, APIs, infrastructure and external attack surface.
// how Argus works
From a scope decision to defensible results.
Argus turns a clearly authorised target into structured security evidence. Automation handles repeatable work; specialists validate material findings, evidence and remediation guidance before delivery.
Explicit scope boundariesAuthorised testing onlySpecialist-reviewed evidence
ARGUS / ENGAGEMENT
Illustrative engagement
B2B SaaS / Web + API
Authorised
01scope decision
02secure intake
03authorisation gate
04Argus execution
05specialist reviewQueued
06results deliveryQueued
07retest and closureQueued
7
controlled stages from decision to closure
1
authorisation gate before testing
PDF + SARIF
portable results when applicable
1 retest
defined verification of reported fixes
// the engagement flow
One controlled flow. Clear ownership at every step.
The process is designed to remove ambiguity early, preserve a traceable evidence chain and keep specialist attention focused on the security decisions that matter.
01 / scope decision
decision
Decide what needs assurance.
We start with the business decision, not an endpoint count. A launch, a customer requirement, a material workflow or a compliance deadline determines the smallest credible assessment boundary.
// You provide
- State the product, decision and deadline
- Identify the workflows that matter most
// Kotav + Argus
- Recommend the smallest suitable service
- Flag complexity that changes the boundary
Output
A clear assessment type, delivery objective and initial boundary — before commercial scope is confirmed.
Illustrative example — no client data
Scope selector
01
Website
Public surface
€490
02
Web application
App + API
Selected
03
Full application
Roles + logic
Extended
Recommended boundary1 app · 1 role · primary API · 3 workflows
02 / secure intake
scope
Turn the product into an explicit scope.
A guided intake captures the exact application, APIs, roles, workflows, environments and exclusions. Completion checks expose missing access or ambiguous boundaries before they become delivery risk.
// You provide
- Provide assets, test accounts and workflows
- Confirm exclusions and sensitive operations
// Kotav + Argus
- Normalise assets, roles and access paths
- Check completeness and surface ambiguity
Output
A testable scope that states what is included, excluded and required — without selling by endpoint count.
Illustrative example — no client data
Engagement / scope
2
assets
1
auth role
3
workflows
app.example.testWEB APPIn scope
api.example.test/v2PRIMARY APIIn scope
CustomerAUTH ROLEProvided
Admin consoleSEPARATE APPExcluded
Ambiguities resolved before any testing begins.
03 / authorisation gate
authorise
Authorise the exact work before it runs.
Testing remains blocked until the Rules of Engagement are approved. The testing window, contacts, stop conditions, data handling and permitted techniques are recorded against the engagement.
// You provide
- Approve the Rules of Engagement
- Nominate technical and emergency contacts
// Kotav + Argus
- Enforce scope hosts and testing limits
- Refuse execution outside the engagement
Output
A traceable authorisation record and a controlled testing window with agreed safety conditions.
Illustrative example — no client data
Rules of Engagement
Authorisation gate passed
Scope, testing window, contacts, exclusions and stop conditions are recorded.
Testing window
12–16 Aug · UTC
Emergency contact
Security lead on file
Data handling
EU-hosted evidence
Stop conditions
3 controls defined
04 / Argus execution
run
Map, test and preserve the evidence trail.
Argus maps the authorised surface, follows authenticated workflows and runs repeatable security checks. Every candidate signal stays tied to the target, test path and source evidence that produced it.
// You provide
- Keep authorised access available
- Answer targeted questions when context is missing
// Kotav + Argus
- Execute bounded web and API validation
- Capture reproducible candidate evidence
Output
A structured queue of signals, coverage and evidence — not an unfiltered scanner export.
Illustrative example — no client data
Argus / validation run
CURRENT WORKFLOW
Invoice access controls
01:42:16
Authentication34 / 34
Authorisation19 / 25
Session controls11 / 19
Input handling16 / 38
116
checks
8
signals
2
review queue
05 / specialist review
review
Validate the signal and test the business impact.
A specialist reproduces material candidates, removes false positives and tests the surrounding authorisation or business logic where human judgment is required. Severity follows verified impact, not tool confidence.
// You provide
- Clarify intended behaviour where necessary
- Confirm material business context
// Kotav + Argus
- Preserve the reproducible evidence chain
- Support focused manual validation
Output
Verified findings with credible severity, affected assets, reproduction, impact and actionable remediation guidance.
Illustrative example — no client data
Specialist review
HIGHCWE-639 · BOLA
Cross-tenant invoice access
A tenant A session retrieved invoice metadata owned by tenant B after changing only the object identifier.
VERIFIED REQUEST
GET /api/invoices/tenant-b-id Authorization: Bearer [tenant-a-session] → 200 OK · ownerTenant: tenant-b
Reproduced Impact confirmed False positive removed Fix reviewed
06 / results delivery
deliver
Deliver results for engineers and decision-makers.
Findings are delivered through the portal with prioritised evidence and remediation guidance. The delivery pack can include an executive view, technical detail, verified evidence, SARIF and an audit-suitable report.
// You provide
- Assign owners and remediation status
- Use the evidence in engineering and GRC workflows
// Kotav + Argus
- Keep findings linked to their evidence
- Produce portable, specialist-reviewed outputs
Output
A usable delivery pack: specialist-reviewed report, verified evidence, remediation priorities and SARIF when applicable.
Illustrative example — no client data
Results / findings
1
critical
2
high
4
medium
9
verified
HIGHCross-tenant invoice accessOPEN
HIGHRefresh token remains valid after logoutOPEN
MEDRate limit bypass on exportACCEPTED
Specialist-reviewed report
07 / retest and closure
retest
Verify fixes and close with evidence.
Within the defined retest window, reported fixes are tested against the original reproduction path. Verified, unresolved and accepted risks remain distinct so the final state is clear.
// You provide
- Notify Kotav when fixes are ready
- Record accepted or deferred risks
// Kotav + Argus
- Replay the relevant validation paths
- Update evidence and finding status
Output
A closure record showing what was fixed, what remains and the evidence supporting each final status.
Illustrative example — no client data
Retest / closure
Before
7open findings
After retest
6fixes verified
Object ownership enforcedVerified
Logout invalidates refresh tokensVerified
Export throttlingRisk accepted
// what you receive
One evidence chain, several useful outputs.
The same verified finding can support an engineering fix, an executive risk decision and an audit conversation. Outputs stay connected to scope, authorisation, reproduction and retest status.
Delivery bundle / v1.0
specialist-reviewed-report.pdf
Executive + technical detail
verified-findings.sarif
Portable engineering output
evidence-pack/
Requests, responses and reproduction
remediation-notes.md
Prioritised developer guidance
Evidence chain complete
Scope → test → review → finding → retest
// one product record
Three assurance moments. One evidence history.
Runtime tests what is deployed. AppSec checks selected code changes. Sentinel re-evaluates retained evidence when the public threat context changes. Active testing still requires an authorised engagement.
02
AppSec
Repository and pull-request assurance with immutable commit identity and customer-controlled policies.
03
Argus Sentinel
A 12-month validation programme built around scheduled Argus runs and bounded human review. It is not a SOC, a 24/7 monitoring service or incident response. Human effort is reserved for material findings, quarterly risk review and two focused manual testing windows.
// start with the boundary
Tell us what needs to be trusted.
We will confirm the smallest credible scope, the access required and the next available testing window.
