Sources and methodology
Radar connects incident reporting to decisions about your own systems. It does not establish whether your organization was compromised.
How a source becomes an update
- 01
Check original sources
Vendor advisories, government notices and original research. Secondary coverage can identify a lead; it does not replace the source for fixed versions.
- 02
Compare the evidence
Review affected products, exploitation, fixes and changed recommendations. Automated checks flag possible changes for review.
- 03
Review before publishing
Drafts may use AI assistance. A human reviewer must approve technical claims, priorities and actions before publication.
- 04
Keep a visible record
Corrections stay on the original page. The editorial record explains what changed. Checking a source does not silently rewrite the article.
How response priority works
Act now identifies urgent review or action, such as reported exploitation, compromised credentials or a deadline. An exception to the priority rules is explained in the editorial record.
This week identifies planned review of important fixes. Monitor covers developments that need more evidence. A missing patch does not by itself make an issue low priority.
What determines the order
Within each priority, Radar lists confirmed exploitation first, followed by credential exposure, observed attempts, dated service impact, working research exploits and vendor precautions. Critical fixes and regional research follow in their respective priority groups. Reviewed CISA KEV matches count as confirmed exploitation within the assigned priority. Equal cases use the editorial deadline, latest update and permanent incident ID; CISA federal due dates do not automatically set a customer deadline.
This is an editorial queue, not a calculated probability of compromise. Check the exposure requirement and affected versions before assigning work. A deadline does not establish exploitation, and a CVSS score does not show whether your systems are affected.
CISA Known Exploited Vulnerabilities
Radar matches CVE identifiers against a reviewed snapshot of CISA’s KEV catalog. The CISA KEV label means that at least one CVE in the incident is listed; the incident page identifies the exact matches and the catalog check date. Inclusion establishes known exploitation, not compromise of your organization. Absence from the snapshot does not rule out exploitation.
The catalog addition date is not the date of the first attack. “Not confirmed” for ransomware means CISA lacks confirmation, not that ransomware use has been excluded. Federal due dates and forensic triage requirements are provided as context; they are not universal obligations for private organizations or businesses in Latin America.
Automated checks identify new entries and changes for editorial review. They do not create public incidents, alter editorial priorities or advance source verification dates. Public evidence remains at the displayed snapshot until a reviewed update is published. Vendor advisories remain the source for affected versions and fixes.
What our labels mean
Observed attempts, a public proof of concept and confirmed exploitation are different findings. We preserve that distinction. Vendor confirmation applies to the reported incident, not to the security of your environment.
Items show when facts were checked and when content changed. If a source cannot be reached, that is a gap to resolve, not evidence that the incident is over.
Corrections and scope
Send corrections to info@oktsec.com with the item URL and supporting source. Do not send secrets or private incident data. Radar is a selected editorial collection, not continuous monitoring of your environment.