Code and supply-chain security (SAST). AI-generated from public sourcesThe starting point for every profile: auto-generated by 0-Doubt from public vendor materials, and not yet confirmed by the vendor or an independent analyst. Nothing here is hidden or overstated — it simply has not been reviewed yet.Where every profile starts, before the vendor or an analyst has reviewed it. A higher label means a more independent source — not a better product.How trust works →
Drawn from this vendor's own public materials and authored to keep category questionnaires balanced. Gaps reflect capabilities not emphasized in public materials, not rankings.
Strengths: Fast, customizable rule-based SAST/SCA/secrets with strong developer adoption and an open core.
Gaps:Rule-based approach can require tuning; DAST and runtime are not the focus.
External ratingsUI-22 — third-party ratingsAggregate rating and review count pulled directly from the source site's own published data — never the review text itself, which belongs to that site. Links go to the real page so you can read the actual reviews there.
IntegrationsUI-12 — integration graphDetected from this vendor's own published integration/partner pages by the enrichment loop — each entry links the exact page it was found on. Directional: "integrates with" is claimed by this vendor; "integrated by" is claimed by the other vendor's site. Coverage grows as the scan progresses.
Trust profileHow to read thisFive separate questions a buyer actually asks, each answered with its own evidence and a link to the source. There is deliberately no overall score: a single number invites comparison it cannot support, and would mostly reflect how much of Semgrep we have managed to scan rather than anything about the vendor.
Not checked means we have not looked yet, and is never counted against a vendor. Limited means we did look, but found only one line of evidence — enough to report, not enough to corroborate.
checked 13 of 16 signals
Limited
Independently verified
Has anyone other than the vendor confirmed this?
checked 3 of 4
1 independent source(s) corroborate this vendor's claims.
How long this vendor has been operating, and who stands behind them.
Security & trust signalsAbout these signalsCertifications are labeled by how well evidenced each one is — confirmed in a public registry, stated by the vendor, or merely detected on a page — and every claim links to its source. Security headers are checked live against the vendor's homepage, re-checked every 90 days. These are independent signals and are not blended into a single score.
9 of 9 technical checks completed — not a score, just coverage
Certifications & compliance claimsWhat the tiers meanVerified in a public registry — we confirmed this against an authoritative public registry (FedRAMP Marketplace, CSA STAR) and re-check it by the registry's own identifier. Stated by the vendor — the vendor says it on a page they control; a sourced claim about themselves, not an independent check. Detected on a page — found during automated enrichment, neither registry-confirmed nor stated on the vendor's own site.
Some certifications have no public registry at all — SOC 2 and HIPAA among them. For those, “not registry-verified” is not a shortfall and means nothing about the vendor.
Some of these (SOC 2, HIPAA and similar) have no public registry, so no one can independently verify them — that is a fact about the framework, not about this vendor.
Security headers (1/5) — checked 10/18/2026
Status historyAbout this timelineEvery incident detected on this vendor's own public status page since we started watching it — sourced from the same structural check as the status chip above, checked roughly hourly (every 5 minutes while an incident is active), never inferred. A resolution requires a real check confirming "operational" again; an incident with no resolution yet shown is still ongoing as of the most recent check.
major outageAug 26, 2026, 5:29 PM – Aug 26, 2026, 6:10 PM42m
major outageAug 17, 2026, 1:59 PM – Aug 17, 2026, 5:02 PM3h 4m
Exploitation riskElevated riskHow this is measuredCombines four public sources, each answering a different question. CVSS (NVD) scores how bad exploitation would be. KEV (CISA) confirms exploitation is happening. EPSS (FIRST) estimates the chance of exploitation in the next 30 days. LEV (NIST CSWP 41) compounds a CVE's own EPSS history into the chance it has already been exploited. “Elevated” means EPSS at or above 10%; LEV is counted as material at 10%. LEV and EPSS are statistical estimates about a vulnerability, not findings about this vendor — and LEV is a stated lower bound, so “10%” means “at least 10%”, never “probably happened”. The underlying CVEs are matched to this vendor by name, not by exact product/version, so check each linked NVD record before drawing conclusions.
2 of 2 CVEs assessed
0
confirmed exploited
0
EPSS ≥ 10%
35%
highest single CVE
Likely-exploited estimates here rest on a median of 2.5 EPSS observations per CVE — too little history to read as a trend yet. It deepens daily as scores are collected.
CVE severity over timeUI-24 — CVE severity timelineEvery known CVE with a disclosure date and severity, plotted by when it was published — lets you see whether disclosures are trending toward more or less severe, not just a raw count. Same NVD-sourced, name-matched data as the list below.
Known CVEs (2)About this listSourced from the public NVD database, matched by vendor name. This is a name-based match, not exact version tracking — always check the linked NVD record for affected versions before drawing conclusions. “New” means published within the last 30 days. “Actively exploited” means CISA's Known Exploited Vulnerabilities (KEV) catalog confirms real-world exploitation, not just a theoretical severity score. An “EPSS” chip appears at 10% and above: that is FIRST's estimated chance of exploitation in the next 30 days, which measures likelihood rather than impact and so can differ sharply from the severity beside it. See the Exploitation risk panel above for the full picture.
In the Linux kernel, the following vulnerability has been resolved:
ixgbevf: fix use-after-free in VEPA multicast source pruning
ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF'…
giturlparse (aka git-url-parse) through 1.2.2, as used in Semgrep 1.5.2 through 1.24.1, is vulnerable to ReDoS (Regular Expression Denial of Service) if parsing untrusted URLs. This might be relevant …
Data coverage: 31/100What this measures (and doesn't)
Not a quality rating or endorsement — a measure of how much verified, disclosed data we actually have about this vendor. A low score usually means "we don't have much verified information yet," not "this is a bad vendor." Never used to sort or rank vendor lists.
The platform admin controls the formula's weights.
Data coverage profileHow to read thisThe same four components behind the data coverage score above, shaped instead of listed — a vendor strong on verification but thin on buyer feedback looks visibly different from one that's the other way around. Security and feedback plot at the neutral midpoint (50) when there's no data yet (no products tracked, no reviews), matching how the actual score itself treats missing data — not a guess either way.
Product information on this page is auto-generated by 0-Doubt from public sources and not yet confirmed by the vendor or an independent analyst, unless an item is individually labelled otherwise. How trust works →
giturlparse (aka git-url-parse) through 1.2.2, as used in Semgrep 1.5.2 through 1.24.1, is vulnerable to ReDoS (Regular Expression Denial of Service) if parsing…
In the Linux kernel, the following vulnerability has been resolved:
ixgbevf: fix use-after-free in VEPA multicast source pruning
ixgbevf_clean_rx_irq() prunes…
Recent changes
last 90 days
CVE-2023-32758 is now estimated at a 34% chance of having already been exploited, despite not appearing on CISA's Known Exploited Vulnerabilities catalog.2026-08-31 · NVD ↗
