Transparency
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.
All signals are sourced from free, publicly available databases. We don't pay for proprietary threat intelligence.
Real-time incident and degradation data pulled directly from vendor-operated status pages.
Signal: Ongoing outages and degradations reported by the vendor themselves.
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.
The authoritative database of all publicly disclosed security vulnerabilities.
Signal: Filtered to CVSS 7.0+ so only HIGH and CRITICAL severity findings surface.
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.
Vulnerability disclosures directly from GitHub's advisory database.
Signal: Covers the open source ecosystem — critical for software supply chain risk.
Troy Hunt's authoritative breach database covering billions of exposed credentials.
Signal: Alerts when a vendor appears in a confirmed data breach.
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.
Every vendor gets a 0–100 score and an A–F grade, combining two independent signals.
A vendor's score has two components: an incident score based on recent security activity, and a posture score based on passive, publicly-observable infrastructure checks. When a vendor has both, they're blended 70/30; when a vendor has no incidents in the window, posture carries the full score.
Built from distinct security findings in the last 90 days, across six signal sources:
More findings lower the score, but with diminishing returns per category — a vendor's first actively-exploited CVE (CISA KEV) matters far more than an already-troubled vendor's eleventh. EPSS exploitation-probability data and CVSS severity both factor into which CVEs count as meaningful; a status-page outage or unresolved finding that keeps recurring day after day is still counted once, not once per day it's re-detected.
Seven passive checks against the vendor's primary domain — no port scanning, no vulnerability scanning, only observation of publicly-advertised signals any browser or DNS resolver would see:
A valid, current certificate on a strong TLS version encrypts data in transit. A weak or expired certificate means traffic to the vendor can potentially be intercepted or tampered with.
Confirms the vendor forces all traffic onto HTTPS rather than allowing a plaintext HTTP connection that a visitor could be silently downgraded to.
Prevents protocol-downgrade and cookie-hijacking attacks by telling browsers to only ever connect over HTTPS, even if a link points to HTTP.
Content-Security-Policy and X-Frame-Options are standard browser-enforced defenses against cross-site scripting and clickjacking — two of the most common web attack classes.
Prevents attackers from spoofing email that appears to come from the vendor's domain — a common vector for phishing customers or employees of the vendor itself.
Cryptographically signs DNS records so they can't be silently forged, protecting against DNS hijacking that could redirect the vendor's traffic to an attacker-controlled server.
Restricts which certificate authorities are allowed to issue certificates for the vendor's domain, reducing the risk of a fraudulently-issued certificate going unnoticed.
Combined (70% incidents / 30% posture)
The vendor has at least one security incident (CVE, breach, or outage) in the last 90 days AND a posture check on file. Recent activity carries more weight, but a strong or weak infrastructure posture still moves the score.
Posture only
No security incidents detected in the last 90 days — the score is based entirely on the posture checks above. A vendor with a clean incident history and strong posture can still land an A.
Insufficient data
The vendor is too new to Gjall's monitoring, or a posture check hasn't run yet and there's no incident history either — no grade is shown until at least one of the two exists.
| Score | Grade | Meaning |
|---|---|---|
| 85–100 | A | Strong security posture, minimal incidents |
| 70–84 | B | Good posture, minor incidents |
| 50–69 | C | Moderate risk — some incidents or posture gaps |
| 30–49 | D | Elevated risk — significant incidents or posture failures |
| 0–29 | F | High risk — critical incidents or major posture failures |
Important caveat on scores
Scores reflect publicly observable security signals — recent incident activity and passive infrastructure checks — not a comprehensive security assessment. A high score means we detected good posture and/or minimal public security activity. It does not mean the vendor is fully secure, and a lower score doesn't necessarily mean your organization is at risk. Always review individual alerts and checks to determine relevance to your specific usage.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.
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.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.
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.
Questions about our methodology?
We're happy to discuss our data sources, scoring logic, or AI model usage in detail.