Findings Library
The Findings Library serves as a centralized repository for security findings in SPEAR. It provides structured storage for vulnerabilities, weaknesses, and strengths, along with sophisticated auto-mapping rules to automatically categorize imported findings.
Overview
Section titled “Overview”The Findings Library enables teams to:
- Maintain a consistent library of security findings
- Standardize vulnerability descriptions and remediation guidance
- Automatically map imported scan results to custom findings
- Organize findings into logical categories
- Track validation status and quality control
Vulnerabilities
Section titled “Vulnerabilities”Vulnerabilities represent specific security issues that can be exploited. They form the core of security assessments and reports.
Fields
Section titled “Fields”| Field | Type | Description |
|---|---|---|
| Title | Text | Descriptive name of the vulnerability |
| Description | Rich Text | Detailed technical description |
| Observation | Rich Text | What was observed during testing |
| Risk Assessment | Rich Text | Impact analysis and risk evaluation |
| Remediation | Rich Text | Steps to fix the vulnerability |
| Severity | Select | Critical, High, Medium, Low, Informational |
| CVSS Score | Number | Common Vulnerability Scoring System (0.0-10.0) |
| CVSS Vector | Text | CVSS vector string for score calculation |
| CVE IDs | Array | Associated Common Vulnerabilities and Exposures |
| CWE IDs | Array | Associated Common Weakness Enumeration |
| Category | Relation | Organizational category |
| References | Array | External reference links |
| isPrebuilt | Boolean | System-provided vs. user-created |
Validation Workflow
Section titled “Validation Workflow”Vulnerabilities progress through validation states:
| State | Description |
|---|---|
draft | Initial state, finding created but not validated |
validated | Finding reviewed and approved for use |
rejected | Finding rejected, requires revision |
Import Sources
Section titled “Import Sources”SPEAR supports importing vulnerabilities from major security tools:
| Tool | Format | Description |
|---|---|---|
| Burp Suite | XML, HTML | Web application scanner results |
| NodeZero | CSV | Autonomous penetration testing |
| Nexpose | XML | Rapid7 vulnerability scanner |
| BloodHound | ZIP | Active Directory attack paths |
| Nessus | XML | Tenable vulnerability scanner |
| Nuclei | JSON | Template-based scanning |
| SPEAR Format | JSON | Standardized import format |
Routes
Section titled “Routes”- List:
frontend/src/routes/console/reports/findings/vulnerabilities/+page.svelte - Detail:
frontend/src/routes/console/reports/findings/vulnerabilities/[id]/+page.svelte
Weaknesses
Section titled “Weaknesses”Weaknesses represent broader security issues that aren’t tied to specific exploitable vulnerabilities. They describe systemic problems or gaps in security controls.
Fields
Section titled “Fields”| Field | Type | Description |
|---|---|---|
| Title | Text | Descriptive name of the weakness |
| Description | Rich Text | Detailed description of the weakness |
| Impact | Rich Text | Potential business impact |
| Recommendations | Rich Text | Suggested improvements |
| Category | Relation | Organizational category |
| Severity | Select | Critical, High, Medium, Low, Informational |
Use Cases
Section titled “Use Cases”- Missing security controls (e.g., no MFA enforcement)
- Process deficiencies (e.g., lack of patch management)
- Configuration issues (e.g., default credentials policy)
- Compliance gaps (e.g., missing audit logging)
Routes
Section titled “Routes”- List:
frontend/src/routes/console/reports/findings/weaknesses/+page.svelte - Detail:
frontend/src/routes/console/reports/findings/weaknesses/[id]/+page.svelte
Strengths
Section titled “Strengths”Strengths represent positive security findings and good practices observed during assessments. They provide balanced reporting by highlighting what the organization does well.
Fields
Section titled “Fields”| Field | Type | Description |
|---|---|---|
| Title | Text | Descriptive name of the strength |
| Description | Rich Text | Detailed description |
| Value Proposition | Rich Text | Why this is beneficial |
| Category | Relation | Organizational category |
Use Cases
Section titled “Use Cases”- Effective security controls (e.g., robust input validation)
- Good practices (e.g., regular security training)
- Strong configurations (e.g., hardened server settings)
- Mature processes (e.g., incident response procedures)
Routes
Section titled “Routes”- List:
frontend/src/routes/console/reports/findings/strengths/+page.svelte - Detail:
frontend/src/routes/console/reports/findings/strengths/[id]/+page.svelte
Categories
Section titled “Categories”Categories organize findings into logical groups for easier management and reporting.
Default Categories
Section titled “Default Categories”- Web Application Security
- Network Security
- Infrastructure Security
- Physical Security
- Social Engineering
- Mobile Application Security
- Cloud Security
- Identity and Access Management
Custom Categories
Section titled “Custom Categories”Create custom categories to match your organization’s taxonomy:
- Navigate to Reports > Findings > Categories
- Click New Category
- Enter name and optional description
- Assign color for visual identification
Routes
Section titled “Routes”- Management:
frontend/src/routes/console/reports/findings/categories/+page.svelte
Auto-Mapping Rules
Section titled “Auto-Mapping Rules”Auto-mapping rules automatically map imported vulnerabilities from scanning tools to your custom findings library. This ensures consistency and saves time when processing large scan results.
How It Works
Section titled “How It Works”- Vulnerabilities are imported from external tools
- Auto-mapping rules evaluate each imported finding
- Matching rules link imported findings to library entries
- Mapped findings inherit standardized descriptions and remediation
Match Criteria
Section titled “Match Criteria”Rules can match on multiple criteria:
| Criterion | Match Type | Description |
|---|---|---|
| Title | Fuzzy/Exact | Match vulnerability title patterns |
| CVE ID | Exact | Match specific CVE identifiers |
| CWE ID | Exact | Match CWE identifiers |
| Severity | Exact | Match severity level |
| Category | Exact | Match finding category |
| Source Tool | Exact | Match import source |
Rule Priority
Section titled “Rule Priority”Rules are evaluated in priority order (lower number = higher priority). The first matching rule wins.
Creating Rules
Section titled “Creating Rules”- Navigate to Reports > Findings > Auto-Mapping
- Click New Rule
- Configure match criteria:
- Set title pattern (supports wildcards)
- Add CVE/CWE filters
- Select severity constraints
- Select target finding from library
- Set priority (default: 100)
- Test rule against sample data
- Save and activate
Testing Rules
Section titled “Testing Rules”Before activating, test rules against existing imported data:
- Click Test Rule on the rule editor
- Review matched findings
- Verify false positive rate
- Adjust criteria as needed
Implementation Reference
Section titled “Implementation Reference”- Page:
frontend/src/routes/console/reports/findings/auto-mapping/+page.svelte - Service:
frontend/src/lib/services/mapping-rules.service.ts
Findings Review
Section titled “Findings Review”The review workflow provides bulk validation capabilities for quality control.
Review Process
Section titled “Review Process”- Navigate to Reports > Findings > Review
- Filter by status (draft, pending review)
- Select findings for bulk review
- Apply validation decision:
- Approve - Mark as validated
- Reject - Mark for revision
- Request Changes - Add notes and return to author
Bulk Operations
Section titled “Bulk Operations”- Select multiple findings with checkboxes
- Apply same validation status to all selected
- Add shared validation notes
- Assign to reviewer
Routes
Section titled “Routes”- Review:
frontend/src/routes/console/reports/findings/review/+page.svelte
Integration with Reports
Section titled “Integration with Reports”Inserting Findings
Section titled “Inserting Findings”Findings from the library can be inserted into reports:
- Open report section editor
- Access findings picker (toolbar button)
- Search or browse library
- Select finding(s) to insert
- Content populates in editor
Linked vs. Copied
Section titled “Linked vs. Copied”- Linked - Changes to library finding update report
- Copied - Finding content copied, no ongoing link
Findings Sections
Section titled “Findings Sections”Report templates can include dedicated findings sections that:
- Display findings table with severity breakdown
- Auto-populate from mapped operations data
- Support custom grouping and sorting
Best Practices
Section titled “Best Practices”Maintain Consistent Naming
Section titled “Maintain Consistent Naming”Use clear, consistent naming conventions for findings:
- Start with the issue type (e.g., “SQL Injection in…”)
- Include affected component or location
- Avoid overly generic titles
Write Actionable Remediation
Section titled “Write Actionable Remediation”Remediation guidance should be:
- Specific and actionable
- Include code examples where appropriate
- Reference best practices and standards
- Provide verification steps
Use Categories Effectively
Section titled “Use Categories Effectively”- Group related findings logically
- Don’t create overly granular categories
- Review and consolidate periodically
Tune Auto-Mapping Rules
Section titled “Tune Auto-Mapping Rules”- Start with high-confidence exact matches
- Add fuzzy matches for known variations
- Monitor false positive/negative rates
- Refine rules based on import results
Technical References
Section titled “Technical References”| Component | Location |
|---|---|
| Findings routes | frontend/src/routes/console/reports/findings/ |
| Auto-mapping page | frontend/src/routes/console/reports/findings/auto-mapping/+page.svelte |
| Mapping rules service | frontend/src/lib/services/mapping-rules.service.ts |
| Backend findings API | backend/api/findings/ |