← back to the portal

Methodology

How we process, classify, and check each story before publishing it.

1. Where the content comes from

Stories come from the public RSS feeds of specialized cybersecurity outlets — the six listed below. Each outlet publishes these feeds openly for other services to consume.

We don't republish their content: from each report we generate an original summary, written in our own words and substantially shorter than the original article, always with attribution to the outlet and a direct link to the full story. The goal is to point you to the source, not to replace it.

To write that summary, the system can read the excerpt the feed itself provides, or the source's original article. The source's text is never stored or published — the only thing saved and shown is our own summary.

This list grows over time. If you know a reliable source we should monitor, you can write to us. And if you run one of these outlets and would rather we didn't include your stories, write to us and we'll remove them.

The educational content in the Classroom section doesn't come from these feeds

It doesn't report a dated event, so it doesn't originate from a news story: it comes from a curated list of cybersecurity topics we maintain ourselves, each with its own editorial brief defining what it must explain and what clarifications it can't skip. The text is written from scratch, limited to well-established, general technical knowledge.

Each topic also cites a recognized public reference — CISA, MITRE, the EFF, the FTC, or FIRST, depending on the topic — and that reference is recommended further reading, not an article the text was summarized from.

2. How often it updates

The pipeline runs periodically to check the feeds above for new content. Every new story it finds goes through the summary and classification process described below before it's published.

3. Deduplication

Each story is uniquely identified by the exact URL of its original source: if that same URL was already processed, it's automatically discarded — never republished, and never worth spending an AI call on again.

4. AI summary and classification

Every new story is sent to a language model (Claude, by Anthropic) with strict instructions: rewrite it completely in its own words (never copy phrases from the original), never invent facts, figures, or CVEs that aren't in the original content, and never reproduce exploit code or leaked personal data even if it appears in the source. All AI-generated content is validated and sanitized before being saved — it's never inserted into the database without an automated format check.

5. Good news / Bad news classification

Every story (except the educational content in the Classroom section) is classified from the perspective of a cybersecurity defense team:

  • Good news — a patch was released, an attacker was arrested, a defensive tool improved, or a vulnerability was responsibly disclosed.
  • Bad news — a new exploitable vulnerability, a data breach, a ransomware attack, or new malware.

Every classification comes with a short sentence explaining why. On top of that, when it applies, every story includes two separate sections:

  • Why it matters — a single sentence with the practical implication for you: what you should check or understand differently because of this story. It's not a summary of the facts — that's already in the body of the report.
  • Defense Path — two or three lines answering what an IT or security team should do about it: update to a specific version, check whether they use a given piece of software, or monitor without immediate action. When the original story doesn't give enough detail for concrete advice, a general recommendation is given instead of inventing technical steps.

Neither one is forced: if there's no clear implication or action to recommend, it's left out instead of being padded with a generic sentence. But when they're there, that's what sets this site apart from a plain headline aggregator: it doesn't just tell you what happened, it tells you where to start if it's on you to act.

6. Relevance

Every story gets a relevance level (high, medium, or low) evaluated specifically for a Spanish-speaking, Mexico-based audience: high if it mentions Mexico, Latin America, or affects software widely used in the region; medium if it's a globally relevant topic; low if it's a very local incident in another region with no clear impact outside it. This scoring wasn't rebuilt for the English edition — it reflects the site's original audience.

7. Severity score (CVSS)

Stories in the Vulnerabilities category that describe a specific flaw get a CVSS score from 0.0 to 10.0. We prioritize the official score, published by the U.S. government's National Vulnerability Database (NVD), when it already exists for the CVE mentioned. If the NVD hasn't published one yet — common for very recent vulnerabilities — the AI generates an estimate based on the standard CVSS factors (attack vector, complexity, privileges required, impact). Estimated scores are always shown marked with an asterisk (*) next to the number, both on cards and in each story's detail view — never presented as if they were official.

8. Confirmed active exploitation (CISA KEV)

When a story mentions one or more CVE identifiers, we automatically cross-reference them against the CISA Known Exploited Vulnerabilities (KEV) public catalog — the U.S. government's official list of vulnerabilities with confirmed evidence of active real-world exploitation. On a match, the story shows the "Active exploitation confirmed" badge — a high-priority signal to act as soon as possible.

CVE identifiers are extracted directly from the already-generated text (the AI isn't asked to invent them or transcribe them from memory), and the match against the CISA catalog is an exact data comparison, not an AI judgment call.

9. Images

Featured images are pulled automatically from Unsplash, under its commercial-use license with visible attribution to the photographer on every photo. They're illustrative: chosen based on the story's category — a padlock for ransomware, a server room for data breaches — not the specific event being reported. They are not photos of the actual incident. We never reuse or re-host copyrighted images from other outlets.

10. Our crawler

When the system needs to read the original article to write the summary, it does so with its own agent, identified as InfoSecDashBot, and it never disguises itself as a browser. Before downloading any page it checks the site's robots.txt and follows what it declares, including Crawl-delay if specified. If an outlet blocks our access, or its server doesn't respond, nothing is downloaded from there: the excerpt provided by the feed itself is used instead.

There's one more layer beyond the technical one. Some outlets explicitly block AI agents in their robots.txt; even when our bot isn't named on those lists and could technically get through, we respect that intent and don't download their articles. The crawler page has all the details: exactly what it does, how to identify it in your logs, and how to block it.

This page explains how the system works. The criteria and commitments it operates under — what gets covered and what doesn't, independence, advertising, and corrections — are in the editorial policy.

In the other direction, our own content is open to AI model training: we don't block those crawlers. See section 5 of the terms of use.

11. Limits of this process

AI-generated content is meant to give you quick context — we always recommend reading the original story (linked in every report) for full coverage. If you spot a factual error in a summary or classification, let us know.