Not every vulnerability comes from a scanner. Penetration test reports, code review notes, bug bounty submissions, customer disclosures and an engineer’s own observation all describe real risk, and in most organisations they live outside the vulnerability management system entirely. Manual Vulnerability Entry is the path that brings those findings into SITEY as first-class records: same database table, same triage, same assignment and the same closure evidence as anything a scanner produced, with imported reports running through the same deduplication as scanner output.
The problem
The findings that matter most are usually the ones a tool did not generate. A pentester chains three low-severity issues into a domain takeover; a reviewer spots a hardcoded credential; a customer emails about an exposed endpoint. None of these have a plugin ID.
So they end up somewhere else. The pentest PDF sits in a shared folder and gets re-typed into a spreadsheet. The spreadsheet has no owner, no SLA clock and no link to the asset. Nobody notices that finding #7 in this year’s report is the same issue as finding #12 in last year’s, because nothing is comparing them. When the auditor asks for evidence that a specific finding was remediated, someone reconstructs a timeline from email threads.
The result is two parallel systems of record, one automated and measured, one manual and invisible, and the manual one is where the highest-severity work usually hides.
How it works
Log the finding
The Log Manual Finding page gives you a single form: vulnerability name, severity (Critical, High, Medium, Low, Info), target IP, port, a rich-text description and a rich-text remediation section.
The form auto-saves a draft to the browser as you type, so a half-finished entry survives a reload or a tab switch. A side panel lists the findings already on file with free-text search and a severity filter, newest first, so you can pick one back up instead of creating a duplicate.
Enrich the technical record
Selecting a finding from that panel loads its full record back into the editor, including the fields that turn a note into an actionable ticket: CVE, CWE, CVSS score, CVSS vector, affected endpoint, vulnerable parameter, file path, service, attack details, technical description, web references, and raw HTTP request and response samples.
These detailed fields are written on update, so the working sequence through the form is to create the record with the core details first, then reopen it and fill in the technical evidence. The CSV importer takes all of the same fields in a single pass, and every save of an existing record stores the previous version as a revision.
Editing a record requires that you created it, or that you hold an admin or manager role.
Bulk-load a whole report as CSV
Entering fifty findings one form at a time is not realistic after an engagement. The Scan Import screen offers a Manual CSV import alongside the scanner importers, with a downloadable template. The importer recognises 23 canonical columns and also accepts common alternative headers, so a spreadsheet exported from someone else’s tooling usually works unchanged:
| You can write | It maps to |
|---|---|
| title, summary | Vulnerability name |
| severity | Risk level |
| ip, host | Target IP |
| url | Endpoint |
| path | File path |
| param | Parameter |
| first_seen, timestamp, detected | Detection date |
Blank rows are skipped, UTF-8 and legacy encodings are both handled, and the response tells you exactly how many new records were created plus a per-row error list for the rows that failed. A bad row is reported, not silently dropped, and it does not abort the rest of the file. Rows that match a finding already on file update that record instead of counting as new.
Deduplicate on the way in
Imported findings go through the same deduplication logic as scanner imports. The match key is name, severity, target IP, port and scanner name, normalised for case.
When a match already exists, SITEY does not create a second open item. It increments the detection count, appends to the detection history, updates the last-seen timestamp and links the new sighting to the original record. Re-importing last quarter’s pentest report next to this quarter’s tells you which findings are genuinely recurring instead of doubling your open count.
Single findings typed into the form are written straight to the record table, so use the side panel search before you create one.
Hand it to the pipeline
From the moment it is saved, a manual finding is treated like a scanner finding by the rest of the platform. Nothing filters records out by where they came from, so it appears in the vulnerability list, the paginated views and the per-IP breakdown next to scanner output, under the same role-based visibility rules as any other record.
It can be run through AI triage, and it carries the same SLA field as every other finding, reported as 72 hours in the vulnerability list when no explicit value has been set. It can be assigned, commented on, archived, bulk-marked or closed.
What you can do
Record a finding with a name, severity, target IP, port, description and remediation, then reopen the saved record to add CVE, CWE, CVSS score and vector, endpoint, parameter, file path, service, attack details and reference links.
Store the raw HTTP request and response that prove the issue, on that same second save or through the CSV import, so the engineer fixing it does not have to reproduce your testing from scratch.
Tag the finding with the tool it actually came from, Acunetix, Nuclei, Nessus, Burp Suite, OpenVAS, Netsparker, Qualys, Fortify, Checkmarx, HCL AppScan, Tenable, or a free-text source, instead of flattening everything to “manual”.
Import an entire engagement as a CSV file and get back a count of the new records created with a per-row error report.
Assign a saved finding to a user, which creates the tracking task and writes an assignment history entry recording who assigned it, to whom and when.
Point a saved finding at a registered agent so it is tied to the host it belongs to rather than floating unattached. New entries start with a generic manual entry marker until you set the agent.
See the full revision history of a record: every edit stores the complete previous field set with a timestamp, and every status change stores the old status, the new status and the user who made it.
Attach evidence files and screenshots to a finding through its comment thread, with file type, size and filename validation and a 10 MB per file limit, and @mention colleagues to pull them in.
Mark a finding false positive, which archives it, or reverse that decision, which restores it.
Bulk archive, unarchive, delete or mark false positive across many findings at once.
Who it is for
Need engagement output to land in the client’s or employer’s tracking system rather than dying as a PDF, and want the request and response evidence stored next to the finding.
Receive findings from many directions, disclosures, threat intel, colleagues, and need one inbox for all of them with deduplication against what is already open.
Receive the finding as an assigned task with the technical detail, the affected host, the port and the suggested fix attached, instead of a forwarded email.
Need to show that manual assessment results were tracked to closure, with a timestamped record of what changed and named attribution on every status change.
Want one open-risk number that includes manual findings, not a dashboard that quietly excludes the most serious work.
Why it matters
The direct saving is re-typing. A 40-finding pentest report that would take an analyst most of a day to transcribe into a tracker becomes a CSV import measured in seconds, with per-row validation instead of silent transcription errors.
The bigger saving is the accounting. Findings in a side spreadsheet have no SLA clock, so they age without anyone being accountable. Findings in SITEY sit in the same queue as scanner output, with the same status workflow, the same assignment and the same SLA field. Deduplication on import means the second and third appearance of a recurring issue strengthens the case for a permanent fix rather than inflating your backlog.
And the audit trail is produced as a by-product of doing the work. Revision records, status change records with attribution, assignment history and comment threads accumulate automatically, so when an assessor asks how a specific finding from an external test was handled, the answer is a record, not a reconstruction.
Works with
- Scanner Integrations, automated findings and manual findings share one record type, and imports share one deduplication path.
- AI Triage. Manually entered findings can be scored for false-positive probability and priority just like scanner output.
- Vulnerability Lifecycle: status transitions, false-positive handling and archiving behave identically regardless of where the finding came from.
- Task Management, assigning a manual finding creates the task and the assignment history behind it.
Frequently asked questions
Do manual findings get the same AI analysis as scanner findings?
Yes. Triage is keyed to the vulnerability record itself, not to its origin, so a manually entered finding can be analysed and scored the same way. The false-positive heuristics work from record metadata: severity against CVSS, presence of a CVE, remediation text, detection count, description completeness. Which means a well-filled-in manual record is analysed more confidently than a sparse one.
What happens if I import the same pentest report twice?
The importer matches on name, severity, target IP, port and scanner name. An existing match is not duplicated as a new open item: its detection count and detection history are updated and the new sighting is linked to the original record. A CSV row also matches a finding you typed into the form earlier, because both paths default to the same scanner name.
Can I keep the name of the tool the finding actually came from?
Yes. Both the entry form and the CSV importer let you set the source and scanner fields, so a finding from a tool you run outside SITEY keeps its real attribution in reports and filters instead of being labelled generically.
Is there a record of what changed on a finding?
Every update stores the complete previous version of the record with a timestamp. Status changes go further: they store the previous status, the new status and the user who made the change. Status changes are also kept as correction records that compare the AI’s assessment with the human decision, so your analysts’ judgement is captured rather than overwritten.
Manual Vulnerability Entry is part of the SITEY platform, and like the rest of it, it runs inside your own infrastructure, so pentest findings and disclosure details never leave your servers. See pricing to get started, or download the installer and import your last engagement report as a CSV to see what deduplication tells you about which findings keep coming back.