Methodology

Yazoul Security aggregates and analyzes public threat intelligence — CVEs, ransomware claims, data breaches, malware activity, and security news — and publishes original offensive-security research. This page documents how content is sourced, produced, and verified, and the editorial standards each section follows.

Data sources

All content is built on top of publicly available threat intelligence feeds. We do not paywall, scrape behind authentication, or republish proprietary data.

• NIST National Vulnerability Database (NVD) — primary CVE source
• CISA Known Exploited Vulnerabilities (KEV) catalog — confirmed in-the-wild exploitation
• FIRST EPSS — exploit prediction scores
• ransomware.live — ransomware victim claim aggregation
• Have I Been Pwned (HIBP) — data breach disclosures
• MalwareBazaar, ThreatFox, URLhaus — malware sample, IOC, and C2 telemetry from abuse.ch
• News correlation across BleepingComputer, The Hacker News, CISA Alerts, and SANS Internet Storm Center
• Public exploit references: GitHub PoC repos, Metasploit Framework, Nuclei templates, Exploit-DB

How content is produced

Yazoul publishes two distinct kinds of content under different bylines and editorial models:

Aggregated intelligence (CVE, breach, news, intel, malware, learn)

Generated by Yazoul AI, an automated pipeline, from the public sources above. These articles are published without a person reading them first, and they carry the Yazoul AI byline so you can tell them apart at a glance. We do not claim original research authorship for them — they synthesize, contextualize, and cross-reference public data.

Editorial scoring rules and source-correlation thresholds are applied programmatically before any AI generation runs, so low-signal items are filtered at the gate rather than after the fact (see Editorial standards below).

Original research (/research/)

Hand-written by named human authors. Yassine B. currently writes this section, focused on offensive-security technique analysis. Articles in /research/ carry his byline and link to his verifiable identity.

Editorial standards

Each pipeline applies a publishing threshold designed to filter low-signal items before they enter the index. These are the actual rules in effect today:

• CVE advisories: a CVE is published only if it scores above our internal relevance threshold and at least one of: CVSS ≥ 8.5; CISA KEV listing; public proof-of-concept (GitHub, Metasploit, Nuclei, or Exploit-DB); or zero-day status. Pure low-impact CVEs without exploitation evidence are not published.
• News articles: stories are only published when reported by 2+ independent sources (or 1 source plus CISA confirmation). We use fuzzy title matching and entity correlation across feeds to avoid republishing single-source claims.
• Ransomware/breach intel: we cover claims publicly listed on ransomware.live with a clear "unverified dark-web claim" disclosure on every article. We do not republish leaked data or link to leak archives.
• Malware reports: family-level activity summaries published weekly, not per-day, to keep each report substantive rather than noisy.
• Data breach reports: ingested from HIBP disclosures with sector context and links to verified data-types.

Update cadence

• Daily: CVE advisories, breach reports, ransomware claims, news
• Every 8 hours: CISA KEV monitor (newly exploited CVEs published immediately)
• Weekly: malware family reports (Sundays), threat roundup (Mondays)
• Monthly: EPSS/KEV re-enrichment of existing CVE pages
• As written: original research articles

Verification & disclosure

Every article links back to the primary public source — NIST entry, vendor advisory, ransomware.live post, HIBP record, or original news outlet. Readers can independently verify any claim.

Dark-web ransomware claims are explicitly labeled as unverified. We do not present an actor's claim as a confirmed breach until the targeted organization or a credible third party corroborates it.

AI-assisted drafting can occasionally produce factual errors, especially around obscure software versions or affected products. When you find one, please report it via the corrections process below — we update or retract on credible reports.

Corrections policy

If you find a factual error, send us an email at [email protected] with the article URL and the specific issue.

Subject line must start with CORRECTION REQUEST | so the message is routed to the editorial queue.

Example: CORRECTION REQUEST | CVE-2026-0300: severity should be CRITICAL (CVSS v4 9.3), not LOW

We aim to respond within 48 hours and either update the article with a clear Updated: note, or retract and replace if the error materially misleads readers. Retracted URLs are removed from the site and return HTTP 404 (Not Found); search engines deindex them on next crawl.

What we don't do

• We do not publish exploitation tooling, working PoCs against unpatched targets, or "how to attack X" guides
• We do not republish leaked data, credential dumps, or breach archives
• We do not cover topics outside cybersecurity (no off-topic content, even for traffic)

Contact

Editorial questions, source tips, or corrections: [email protected].

Public profiles for the named editors are linked from each article's byline.