Skip to main content

Transparency

How Gjall Works

Transparent methodology for vendor risk monitoring

Gjall aggregates publicly available security signals and applies AI analysis to help you understand risk across your vendor portfolio. Here's exactly how — including what we don't do.

Data Sources

All signals are sourced from free, publicly available databases. We don't pay for proprietary threat intelligence.

Statuspage.io API

Real-time incident and degradation data pulled directly from vendor-operated status pages.

Signal: Ongoing outages and degradations reported by the vendor themselves.

Updated: Every 15 minutesFree

CISA Known Exploited Vulnerabilities

The US government's curated list of vulnerabilities confirmed to be actively exploited in the wild.

Signal: Highest-signal security feed available — zero noise by design. Every entry is a confirmed exploit in active use.

Updated: DailyFree

NIST NVD CVE Database

The authoritative database of all publicly disclosed security vulnerabilities.

Signal: Filtered to CVSS 7.0+ so only HIGH and CRITICAL severity findings surface.

Updated: Every 15 minutesFree

EPSS — Exploit Prediction Scoring System

A probability score (0–100%) from FIRST.org estimating the likelihood a CVE will be exploited in the next 30 days.

Signal: Combined with CVSS severity for better prioritization — most high-CVSS CVEs are never exploited.

Updated: DailyFree

GitHub Security Advisories

Vulnerability disclosures directly from GitHub's advisory database.

Signal: Covers the open source ecosystem — critical for software supply chain risk.

Updated: ContinuousFree

HaveIBeenPwned

Troy Hunt's authoritative breach database covering billions of exposed credentials.

Signal: Alerts when a vendor appears in a confirmed data breach.

Updated: DailyFree

HackerNews

Community-sourced incident detection via the tech community's primary discussion forum.

Signal: Security incidents often surface on HackerNews before vendor status pages are updated.

Updated: Every 15 minutesFree

How Risk Scores Are Calculated

Each vendor receives a 0–100 score based on recent signal volume. Scores decay over time.

Each vendor receives a risk score from 0–100 based on recent security signals. Scores decay automatically over time as incidents age — reflecting that a vendor's current posture matters more than historical events.

Score signals

SignalPoints
CRITICAL alert (CISA KEV or CVSS 9.0+)+20 pts
HIGH alert (CVSS 7.0–8.9)+10 pts
MEDIUM alert+5 pts
Each day without new incidents−5 pts (decay)

Score levels

ScoreLevelMeaning
80–100CriticalSignificant recent security activity
60–79HighNotable recent security activity
40–59MediumSome recent security activity
0–39LowMinimal recent security activity

Important caveat on risk scores

Risk scores reflect the volume and severity of security signals detected for a vendor — not an assessment of the vendor's overall security posture. A high score means we detected significant public security activity. It does not mean the vendor is insecure or that your organization is at risk. Always review individual alerts to determine relevance to your specific usage.

How AI Triage Works

For HIGH and CRITICAL alerts, Claude (Anthropic) provides additional context.

Raw vulnerability data is hard to prioritize. For HIGH and CRITICAL alerts, Gjall passes the public alert data through Claude to generate four pieces of additional context:

Confidence score

0–100% estimate of how likely this alert affects a typical customer of the vendor.

Priority classification

Immediate / This Week / Monitor / Ignore — actionable triage guidance.

Plain English summary

Non-technical explanation of the issue and its potential business impact.

Recommended actions

Specific next steps with rough effort estimates (e.g., 'Rotate API keys — 15 min').

Data privacy

What we send to AI: Only the CVE description, vendor name, severity score, and EPSS data — all publicly available information.

What we never send: Your company name, customer ID, which vendors you monitor, or any identifying information.

Training: Anthropic's API does not train models on API data per their commercial terms.

How Vendor Criticality Is Determined

A three-step process with mandatory human review.

Auto-classification

For well-known vendors (Stripe, Okta, AWS, GitHub, Cloudflare, etc.) Gjall pre-classifies criticality based on vendor type and typical enterprise usage patterns.

AI-assisted classification

For unknown vendors, Gjall asks four business questions and uses AI to suggest a criticality tier. The suggestion is based solely on how your organization uses the vendor, not on the vendor's general reputation.

Human confirmation (required)

All AI suggestions must be reviewed and confirmed by a qualified person at your organization before they affect monitoring behavior. Unconfirmed vendors default to Medium criticality.

Disclaimer

AI criticality suggestions are informational only and do not constitute professional security advice. Your organization retains full responsibility for vendor risk classifications. By confirming a classification, an authorized person at your organization acknowledges they have reviewed and approved the assessment.

How Gjall Supports Compliance

Supporting evidence — not certification.

Gjall's monitoring activity generates evidence that supports specific SOC 2 and ISO 27001 controls. Audit reports map each piece of evidence to the relevant control automatically.

SOC 2 Type II

  • CC9.2Vendor Risk Management: Vendor inventory, criticality tiers, and immutable audit trail.
  • CC7.1Vulnerability Detection: NVD and CISA KEV polling surfaces HIGH/CRITICAL CVEs.
  • CC7.2Security Event Monitoring: Status page incidents, CVE disclosures, and breach data classified by severity.
  • CC7.3Security Event Evaluation: AI triage assigns priority and recommended actions to critical alerts.
  • A1.1Availability Monitoring: Status page polling provides continuous availability evidence.

ISO 27001:2022

  • A.5.19Supplier Relationships: Documented vendor register with criticality classifications.
  • A.5.20Supplier Agreements: Criticality confirmations create an auditable acknowledgement record.
  • A.5.21ICT Supply Chain: CVE and CISA KEV monitoring surfaces supply-chain vulnerabilities.
  • A.5.22Supplier Service Monitoring: Continuous scanning with immutable S3 alert log.
  • A.8.8Technical Vulnerabilities: CVE pipeline with CVSS, CISA KEV, and EPSS prioritization.
  • A.8.16Monitoring Activities: Scheduled polling with Slack/email dispatch and audit logging.
Gjall generates evidence supporting these controls. It does not certify compliance. Work with a qualified auditor to determine which controls apply to your organization and whether Gjall's output is sufficient for your specific audit requirements.

Important Limitations

What Gjall doesn't do — and why it matters.

We believe in being explicit about what our product can and cannot do. These are real limitations, not fine print.

  • Gjall monitors public signals only — we do not scan vendor infrastructure or perform penetration testing.
  • Signals are sourced from public databases — there may be a delay between a vulnerability being discovered and appearing in our feeds.
  • AI triage provides context, not advice — outputs should be reviewed by qualified security personnel.
  • Risk scores are based on signal volume, not a comprehensive security assessment.
  • Gjall is not a substitute for vendor security questionnaires, contracts, or professional due diligence.
  • Vendor status pages may be incomplete or delayed — some incidents are never officially reported.

Questions about our methodology?

We're happy to discuss our data sources, scoring logic, or AI model usage in detail.