Evidence and file security
How uploaded evidence is stored, encrypted, scanned and quarantined — and how access to it is controlled.
Vulnerability reports contain screenshots of production systems, packet captures, credentials used during testing and sometimes customer data. Evidence handling is therefore a security control in its own right, not a file-upload feature.
Upload modes
Files are stored in one of two modes, chosen deliberately per asset:
| Mode | Intended for | Behaviour |
|---|---|---|
| Public | Non-sensitive material such as program policy attachments or published advisories | Stored without content encryption |
| Confidential | Reports, evidence, credentials, anything customer-specific | Encrypted at rest before storage |
Reports and their attachments are confidential by default, because that is what they are.
Encryption at rest
Confidential assets are encrypted with AES-256-GCM before being written to storage. This is authenticated encryption, so tampering with stored content is detectable rather than silent. Keys are held separately from the encrypted objects, and every file operation is authenticated — an object identifier alone is not sufficient to retrieve a file.
Malware scanning
Uploads are not assumed to be benign. Each file passes through multiple scanning engines:
- ClamAV for known-signature detection.
- VirusTotal for multi-engine analysis.
- File-type validation — blocked and dangerous types are rejected before storage, so a renamed executable does not slip through on extension alone.
- Automatic quarantine — anything flagged is quarantined rather than delivered, and the uploader is informed.
A quarantined file is not deleted silently: the flow records the decision so the reporter knows what happened and can re-submit in a different form where appropriate.
Access control
- Authenticated operations — every file read, write and delete is authorised against the caller's identity and permissions.
- Program-scoped access — a researcher sees the evidence attached to their own reports; a program owner sees their program's; an unrelated participant sees neither.
- Least privilege by default on administrative downloads.
- Streaming download and delete — files are streamed rather than buffered, which matters for large evidence sets and for deletion at scale.
Retention and deletion
- Evidence is retained against the finding record so a closure decision remains verifiable.
- Deletion is available at file and record level, subject to the retention rules your programme sets.
- Deletion is an auditable action: who deleted what and when is recorded.
Practical guidance for programs
- State evidence expectations in the policy. Ask for the smallest artefact that proves the issue — a request/response pair usually beats a video.
- Ask researchers not to paste real customer data. Where data is unavoidable, ask for redacted copies.
- Prefer test accounts to production credentials on expert engagements, and use the credential locker when real access is needed.
- Treat quarantine as a signal. A quarantined attachment from a new account is worth a second look before it is re-uploaded elsewhere.
Availability and limits
- Encrypted storage, multi-engine scanning, quarantine and access-controlled file operations are part of the platform's baseline security model.
- VPN-assisted access and source code review artefacts are Professional-tier.
- Evidence handling describes how the platform protects stored material. It does not make an organisation's own retention or privacy obligations disappear — those remain yours.
Related docs
- Identity and access — the access model behind file operations
- Triage pipeline — where evidence enters the workflow
- Remediation and verification — retest evidence and proof of fix