Security automation platform
VulnScope
A black-box-first application security platform that coordinates assets, scan state, workers, and normalized results without turning the product into a thin wrapper around scanner commands.
- Role
- Product and platform engineering
- Context
- VulnScope is designed as a security product for repeatable HTTP, TLS, and network discovery workflows across isolated workspaces.
- Current status
- The architecture is documented publicly. A live application and source repository are not linked until their availability is confirmed.
Challenge
Scanner execution is only one part of DAST. The larger system must maintain canonical target identity, isolate tenants, dispatch work reliably, make scan progress inspectable, and preserve the difference between actionable findings and contextual observations.
Architecture
Boundaries before implementation detail.
The system is organized around explicit responsibility, durable state, and observable handoffs.
Workspace API
Authenticates users, resolves workspace context, and accepts operations against canonical assets.
Domain + PostgreSQL
Owns assets, scan intent, state transitions, sessions, findings, observations, and tenant boundaries.
Transactional outbox
Records dispatch intent in the same transaction as domain state so work is not lost between persistence and queue publication.
Celery workers
Execute bounded tasks and report outcomes without becoming the source of truth for scan lifecycle state.
Scanner adapters
A focused HTTP/TLS scanner and Nmap integration return normalized evidence through explicit adapter boundaries.
Result model
Stores actionable findings separately from observations that add context without asserting a vulnerability.
Key decisions
Decisions that shape the product.
Each choice defines a boundary the system can explain, test, and evolve.
Black-box first
The initial product boundary models externally observable behavior. Additional analysis modes can be added later without redefining the core asset and scan lifecycle.
Canonical assets
Targets are normalized into stable asset identities before scanning, reducing duplicate state and keeping results attached to the same domain object.
Replay-aware sessions
Short-lived access tokens are paired with rotating refresh sessions. Reuse of an already rotated refresh token invalidates its session lineage.
Transactional dispatch
The outbox makes persistence and work publication recoverable without pretending that a database and task broker share one atomic transaction.
Authoritative scan state
Workers report facts back to the application; PostgreSQL applies valid state transitions and remains authoritative during retries or worker loss.
Findings are not observations
A finding represents a security issue with actionable evidence. An observation records useful context without overstating risk.
Security considerations
Security is part of the system model.
Controls sit at data, identity, execution, evidence, and disclosure boundaries.
Workspace tenancy
Workspace context is part of data access and command handling so isolation does not depend on client-side filtering.
Scanner safety boundaries
Authorized target scope must remain attached to scan intent, and adapters must not broaden targets implicitly during execution.
Authentication lifecycle
Rotation, replay detection, revocation, and session lineage are treated as one lifecycle rather than independent token checks.
Evidence handling
Results retain the context needed for review while public documentation excludes credentials, secrets, private addresses, and raw sensitive logs.
Testing strategy
Test the boundaries that carry risk.
- 01
Domain tests
Exercise asset canonicalization, allowed scan-state transitions, result classification, and tenant-aware command rules.
- 02
Integration tests
Cover PostgreSQL persistence, outbox publication, worker callbacks, refresh rotation, and replay handling at system boundaries.
- 03
Scanner contracts
Use controlled fixtures to check HTTP/TLS and Nmap normalization without depending on unbounded external targets.
- 04
Manual QA
Walk through workspace isolation, asset creation, scan progress, retry and failure states, result classification, and keyboard-accessible operator flows.
Result / current status
The design establishes durable boundaries between product state, work dispatch, scanner execution, and security evidence. It provides a coherent base for expanding scanner coverage without giving workers or integrations ownership of the domain model.
Current limitations
- No public live deployment or source repository is currently configured for this portfolio.
- Current documented scanner breadth is limited to the focused HTTP/TLS scanner and Nmap integration.
- Production scale, adoption, coverage, and performance figures are not published because they have not been confirmed.
Next steps
- Add scanner adapters only through the existing bounded result and execution contracts.
- Deepen operational visibility around outbox recovery, worker retries, and scan-state history.
- Publish live and source links only after their public availability and security posture are confirmed.
Lessons
What carries forward.
- Security automation becomes a product when state, failure, tenancy, and evidence are modeled explicitly.
- A queue is an execution mechanism, not the source of truth for business state.
- Result vocabulary affects product trust: observations must not silently become findings.