Guides for Security Analysts

These guides cover the day-to-day workflows you'll use most: running scans, reviewing findings, creating reports, and managing exceptions.

---

Guide 1: Running Your First Vulnerability Scan

Learn how to set up a target, choose a scan type, kick off a scan, and review the results.

Time needed	15 minutes
Prerequisites	ThreatWeaver account with Analyst role or higher
What you'll learn	How to add a scan target, configure a scan, monitor progress, and view findings

How it works

Before diving in, here is a quick look at the overall scan workflow:

Steps

1. Navigate to the AppSec module. From the left sidebar, click AppSec. This opens the scanner dashboard where you manage assessments, targets, and findings.

2. Add a target. Click Targets in the AppSec sidebar, then click + Add Target. Enter the base URL of the application you want to scan (for example, https://staging.myapp.com). Give it a friendly name so your team recognizes it later.

3. Create a new assessment. Go to Assessments and click + New Assessment. Select the target you just added.

4. Choose your scan type.

   Scan Type	Best For	Coverage
   Black Box	External attacker simulation. No credentials needed.	Finds publicly-exposed issues.
   Gray Box	Testing with a regular user account. Most common choice.	Finds auth boundary issues (BOLA, BFLA, IDOR).
   White Box	Maximum coverage. You provide credentials plus test data.	Deepest scan -- tests internal logic and data access.

   Start with a Quick Scan

   If this is your first time, choose Black Box with a Quick Scan template. It runs faster and gives you a feel for the results before committing to a full DAST scan.

5. Configure authentication (if needed). For Gray Box or White Box scans, you need to provide login credentials. Click Auth Profile and either select an existing profile or create a new one. See the Authenticated Scanning guide for detailed instructions.

6. Start the scan. Click Start Scan. You will see the assessment status change to Running.

7. Monitor progress in real-time. The assessment page shows live progress:

   • Phase indicators -- which of the 6 phases is currently active (Recon, Discovery, Scanning, Exploitation, Validation, Reporting)
   • Finding count -- how many findings have been detected so far
   • Agent activity -- which of the 59 scanner agents are actively testing

8. Review findings when complete. Once the scan finishes, the status changes to Completed. Click into the assessment to see all findings, sorted by severity (Critical > High > Medium > Low > Info).

What happens during a scan?

ThreatWeaver runs up to 59 specialized agents in parallel. Each agent tests for different vulnerability types -- SQL injection, XSS, SSRF, broken access control, and more. After all agents finish, a validation pipeline filters out false positives, deduplicates results, and assigns confidence scores. This whole process typically takes 10-30 minutes depending on the application size.

Don't scan production without permission

Always get approval before scanning a production environment. Scans send real HTTP requests that could trigger alerts or, in rare cases, affect application state. Use staging or dev environments when possible.

---

Guide 2: Reviewing and Triaging Findings

Learn how to read a finding, verify it, and decide what to do next.

Time needed	10 minutes per finding
Prerequisites	A completed scan with findings
What you'll learn	How to interpret finding evidence, mark false positives, create exceptions, and assign remediation

Understanding a finding

Each finding includes:

Field	What it tells you
Severity	Critical, High, Medium, Low, or Informational. Based on potential business impact.
CVSS Score	Industry-standard 0-10 score. Higher = more severe.
Confidence	How certain ThreatWeaver is that this is a real vulnerability (0-100%).
Vulnerability Type	The category (e.g., SQL Injection, Cross-Site Scripting, Broken Access Control).
Affected Endpoint	The exact URL and HTTP method where the issue was found.
Evidence	The actual HTTP request and response that proves the vulnerability exists.
Remediation	Suggested fix steps specific to the technology stack.

Steps

1. Open the findings list. Navigate to your completed assessment and click Findings. The list is sorted by severity by default -- Critical issues appear first.

2. Read the evidence carefully. Click on a finding to expand it. Look at the Evidence section:

   • Request: The exact HTTP request that triggered the vulnerability. Pay attention to the injected payload.
   • Response: What the server returned. Look for signs that the payload was executed (e.g., database errors for SQLi, reflected content for XSS).

3. Verify the finding. Ask yourself:

   • Does the response actually show exploitation? (e.g., database error messages, reflected script tags)
   • Is the affected endpoint real and in-scope?
   • Could this be a false positive? (e.g., the app returned an error for a different reason)
   Use confidence scores to prioritize

   Findings with confidence above 80% are almost always genuine. Focus your manual review on findings between 50-80% -- these are the ones most likely to need human judgment.

4. Take action on each finding.

   Action	When to use it
   Confirm	You have verified the vulnerability is real. It stays open for remediation.
   Mark as False Positive	You have confirmed the finding is not a real vulnerability. Provide a reason (e.g., "WAF blocks this in production").
   Create Exception	The vulnerability is real but you accept the risk. See Managing Exceptions.
   Assign to Developer	Route the finding to the responsible team for remediation. Optionally generate a Jira ticket via AI Ticket Writer.

5. Prioritize your remediation queue. Work through findings in this order:

   1. Critical severity -- fix immediately
   2. High severity -- fix within your SLA (typically 30 days)
   3. Medium severity -- schedule for the next sprint
   4. Low / Info -- track but address when convenient

Compliance tip

If you are preparing for a PCI-DSS or SOC 2 audit, Critical and High findings must be remediated or have documented exceptions before the audit period ends.

---

Guide 3: Creating Compliance Reports

Generate reports mapped to industry compliance frameworks.

Time needed	5 minutes
Prerequisites	At least one completed scan
What you'll learn	How to generate reports for PCI-DSS, SOC 2, ISO 27001, and HIPAA

Supported frameworks

Framework	Focus Area
PCI-DSS	Payment card data protection
SOC 2	Service organization controls (security, availability, confidentiality)
ISO 27001	Information security management system
HIPAA	Healthcare data protection

Steps

1. Navigate to the Compliance tab. In the AppSec module sidebar, click Compliance. This shows your current compliance posture across all frameworks.

2. Select a framework. Click on the framework you need (e.g., PCI-DSS). You will see a breakdown of controls, showing which are passing, failing, or not yet assessed.

3. Choose your scope. Select which assessments and targets to include in the report. You can scope it to a single application or across your entire portfolio.

4. Generate the report. Click Generate Report. ThreatWeaver maps your scan findings to the specific controls in the chosen framework and produces a structured document.

5. Download as PDF. Once generated, click Download PDF. The report includes:

   • Executive summary with pass/fail rates
   • Control-by-control breakdown
   • Evidence for each failed control
   • Remediation recommendations

6. Share with auditors. The PDF is designed to be auditor-friendly. You can email it directly or upload it to your audit management platform.

Use AI Executive Summary for non-technical stakeholders

For a more readable version, use the AI Executive Summary Generator in AI Labs. It produces a narrative summary that non-technical executives and board members can understand.

---

Guide 4: Managing Scan Exceptions

Learn when and how to create exceptions for vulnerabilities you choose to accept.

Time needed	5 minutes per exception
Prerequisites	An open finding that needs an exception
What you'll learn	How to create, manage, and review exceptions

When to create an exception

Exceptions are appropriate when:

Reason	Example
Accepted Risk	The vulnerability exists but a compensating control mitigates it (e.g., WAF rules block the exploit pattern).
False Positive	The scanner flagged something that is not actually exploitable in your environment.
Compensating Control	A different security mechanism addresses the same risk (e.g., network segmentation).
Business Decision	The cost of remediation exceeds the risk, and leadership has approved acceptance.

Steps

1. Open the finding. Navigate to the finding you want to create an exception for.

2. Click "Create Exception". You will see a form with the following fields:

   Field	What to enter
   Reason	Select from: Accepted Risk, False Positive, Compensating Control, or Won't Fix.
   Justification	Write a clear explanation of why you are accepting this risk. Be specific -- auditors will read this.
   Expiration Date	Set a review date. Most teams use 90 days. The exception will need to be renewed or the finding will reopen.
   Approver	Select the manager or security lead who approved this exception.

   Use the AI Exception Assistant

   The Exception Assistant in AI Labs can help you draft a well-written justification that meets audit standards. It evaluates your compensating controls and suggests improvements.

3. Submit for approval. The exception goes to the designated approver. They will receive a notification to review and approve or reject it.

4. Track exception status. Once approved, the finding is marked as Accepted and no longer counts toward your open vulnerability metrics. However, it is still visible in the exceptions list.

How exceptions affect compliance

• Accepted exceptions are excluded from compliance failure counts.
• They are included in compliance reports as documented accepted risks.
• Auditors expect to see a clear justification and a review cycle for each exception.

Quarterly exception review

Review your exceptions regularly

Set a calendar reminder to review exceptions quarterly. Ask:

• Is the compensating control still effective?
• Has the risk landscape changed?
• Should the exception be renewed or should remediation begin?

Expired exceptions automatically reopen the finding, so do not let them lapse without a decision.

---

Next steps

• Setting Up Authenticated Scanning -- find more vulnerabilities with Gray Box or White Box scans
• Generating Executive Reports -- present findings to leadership
• Glossary -- look up unfamiliar terms
• FAQ -- answers to common questions