AppSec Reporter

Overview

The AppSec Reporter is an automated security finding ingestion and management platform that collects vulnerabilities from multiple security tools — including Snyk, Cycode, Wiz, and Tenable — normalizes them into a common schema, and synchronizes them with Jira for tracking and remediation. It provides a unified view of your organization's security posture across all scanning tools and repositories.

System Architecture

The AppSec Reporter is built on a modern stack consisting of a React single-page application served through Nginx, backed by a FastAPI Python backend and PostgreSQL database. Modular adapters connect to each security tool, and a dedicated Jira adapter handles issue creation and synchronization.

┌──────────────┐     ┌──────────┐     ┌────────────────────┐
│  React SPA   │────>│  Nginx   │────>│  FastAPI Backend   │
└──────────────┘     └──────────┘     └─────────┬──────────┘
                                                 │
                          ┌──────────────────────┼──────────────────────┐
                          │                      │                      │
                   ┌──────▼──────┐       ┌───────▼───────┐     ┌───────▼───────┐
                   │ PostgreSQL  │       │ Tool Adapters │     │ Jira Adapter  │
                   │  Database   │       │ (Snyk, Cycode,│     │               │
                   └─────────────┘       │  Wiz, Tenable)│     └───────────────┘
                                         └───────────────┘

How Vulnerabilities Are Collected

Each security tool is accessed through a dedicated adapter module. The adapters follow a consistent pattern:

  • Authentication — Each adapter authenticates with its respective tool using encrypted API credentials stored securely with Fernet encryption.
  • Pagination — Adapters handle paginated API responses transparently, iterating through all pages until every finding is retrieved.
  • Retry with Backoff — Transient errors and rate limits are handled with exponential backoff retry logic, ensuring reliable data collection even under adverse network conditions.
  • Normalization — Raw findings from each tool are transformed into a common internal schema, mapping tool-specific fields (severity, CVE identifiers, affected assets) to a unified data model.
  • Upsert and Deduplication — Findings are upserted into PostgreSQL, deduplicated by the composite key (source_tool, source_issue_id). This ensures that repeated syncs do not create duplicate records and that existing findings are updated with the latest state.

EPSS Vulnerability Prioritization

The AppSec Reporter enriches vulnerability data with EPSS (Exploit Prediction Scoring System) scores retrieved daily from the FIRST.org EPSS API. EPSS provides a probability score indicating the likelihood that a vulnerability will be exploited in the wild within the next 30 days, along with a percentile ranking.

The exploitability rating is determined by the following algorithm:

def get_exploitability_rating(epss_score, epss_percentile):
    if epss_score >= 0.50 or epss_percentile >= 0.95:
        return "Critical"
    elif epss_score >= 0.20 or epss_percentile >= 0.80:
        return "High"
    elif epss_score >= 0.05 or epss_percentile >= 0.50:
        return "Medium"
    else:
        return "Low"

This prioritization ensures that vulnerabilities most likely to be exploited in the wild are surfaced first, enabling security teams to focus remediation efforts where they matter most.

Automated Reporting Workflow

The end-to-end reporting workflow consists of eight steps:

  1. Trigger — A sync is initiated on a schedule (e.g., daily) or manually by an analyst through the UI.
  2. Authenticate — The system decrypts stored credentials and authenticates with each configured security tool.
  3. Fetch — Adapters retrieve all current findings from each tool, handling pagination and retries.
  4. Normalize — Raw findings are transformed into the common internal schema.
  5. Upsert — Normalized findings are upserted into PostgreSQL, deduplicated by source tool and issue ID.
  6. Route via CMDB — Each finding is mapped to a Jira project and assignee team using CMDB (Configuration Management Database) lookup based on the affected repository or asset.
  7. Create Jira Issues with SLA Due Dates — Jira tickets are created (or updated) for each finding, with priority and SLA due dates assigned based on severity.
  8. Record Sync History — The sync run is logged with timestamps, counts, errors, and status for auditing and troubleshooting.

Developer-Friendly Output

Jira tickets created by the AppSec Reporter are designed to give developers all the context they need to remediate a finding efficiently. Each ticket includes:

  • Severity — The normalized severity of the vulnerability
  • Affected Repository — The specific repository or asset where the vulnerability was detected
  • CVE Identifier — The CVE ID, linked to the NVD entry for full details
  • Remediation Guidance — Steps to fix the issue, including upgrade paths or configuration changes
  • Direct Links — Links back to the original finding in the source security tool for additional context

Priority is mapped to Jira priority levels and SLA timelines as follows:

Severity   │ Jira Priority │ SLA Due Date
───────────┼───────────────┼─────────────
Critical   │ Highest       │ 30 days
High       │ High          │ 60 days
Medium     │ Medium        │ 90 days
Low        │ Low           │ 180 days

Data Flow

The full data pipeline flows from security tools through to Jira and the reporting dashboard. Security tool adapters pull raw findings from Snyk, Cycode, Wiz, and Tenable. These raw findings are normalized into a common vulnerability schema and upserted into PostgreSQL, deduplicated by source tool and issue ID. EPSS scores are fetched daily and joined to findings by CVE. The CMDB routing layer maps each finding to the appropriate Jira project and team based on the affected repository or asset. Jira tickets are created or updated with severity, SLA due dates, remediation guidance, and direct links. Finally, the React SPA provides dashboards, filtering, and export capabilities for security analysts and management reporting.

Example Use Case

Consider the following scenario: Snyk detects a critical CVE in the org/api-service repository during a scheduled scan. The AppSec Reporter's Snyk adapter fetches the finding and normalizes it into the common schema. During the CMDB routing step, the system looks up org/api-service and determines it belongs to the SEC Jira project, owned by the platform-team. A Jira ticket is automatically created in the SEC project with:

  • Priority set to Highest (Critical severity)
  • SLA due date set to 30 days from detection
  • Full CVE details, remediation steps, and a link back to the Snyk finding
  • Assignment to the platform-team's triage queue

The platform team receives the ticket, reviews the remediation guidance, applies the fix, and closes the ticket — all tracked and auditable through the AppSec Reporter.

Technical Advantages

  • Modular Adapters — Each security tool integration is a self-contained adapter module, making it straightforward to add new tools without modifying the core pipeline.
  • Fernet Encrypted Credentials — All API keys and tokens are stored encrypted at rest using Fernet symmetric encryption, ensuring secrets are never exposed in plaintext.
  • RBAC (Role-Based Access Control) — The platform enforces three roles: viewer (read-only dashboards), analyst (trigger syncs, manage findings), and admin (full configuration and user management).
  • Rate Limiting — API endpoints are rate-limited to prevent abuse and ensure stable performance under load.
  • Structured JSON Logging — All application logs are emitted in structured JSON format, making them compatible with centralized logging systems (ELK, Datadog, Splunk) for monitoring and alerting.
  • Audit Trail — Every sync run, finding change, and Jira action is logged with timestamps and user context, providing a complete audit trail for compliance and incident response.