| name | cyberowlai |
| description | Check if recent cybersecurity alerts from 10 international CERTs affect your current project. Use when the user asks about security vulnerabilities, CVEs, "is my project affected", "any new security alerts", "check for vulnerabilities", "cyberowlai", or "/cyberowlai". Also trigger when the user is working on dependency updates, Dockerfile changes, security audits, or any security-related task — even if they don't explicitly mention CyberOwl AI. Trigger on questions like "should I update my dependencies", "are there any new CVEs for X", "security check", or "what vulnerabilities should I worry about". If the user mentions a specific CVE or advisory ID, use this skill to cross-reference it against their stack.
|
CyberOwl Security Check
Cross-reference recent cybersecurity alerts from 10 international CERTs
against the user's project to surface vulnerabilities that actually matter to
them.
High-level workflow
- Discover the project's full tech stack (dependencies, infra, frameworks)
- Fetch the alert feed from
https://cyberowlai.com/alerts.json
- Match alerts against the stack using tiered confidence
- Report only what's relevant, plus always-flag critical alerts
Run steps 1 and 2 in parallel when possible — don't make the user wait.
Step 1 — Deep project discovery
Build a comprehensive inventory. Go beyond top-level deps — look at
transitive dependencies, container base images, CI tool versions, and code
import patterns.
1a. Find all dependency and config files
Use Glob to locate files. Search for all of the following (skip categories
that return nothing):
| Category | Files to find |
|---|
| Node.js | package.json, package-lock.json, yarn.lock, pnpm-lock.yaml |
| Python | requirements.txt, Pipfile, Pipfile.lock, pyproject.toml, poetry.lock, setup.py, setup.cfg |
| Go | go.mod, go.sum |
| Ruby | Gemfile, Gemfile.lock |
| Java/Kotlin | pom.xml, build.gradle, build.gradle.kts |
| Rust | Cargo.toml, Cargo.lock |
| PHP | composer.json, composer.lock |
| C#/.NET | *.csproj, packages.config, Directory.Packages.props |
| Swift | Package.swift |
| Dart/Flutter | pubspec.yaml |
| Elixir | mix.exs |
| Perl | cpanfile |
| Containers | Dockerfile, Containerfile, docker-compose.yml, docker-compose.yaml |
| Kubernetes | *.yaml in k8s/, kubernetes/, deploy/, manifests/ |
| Helm | Chart.yaml, values.yaml |
| Terraform | *.tf |
| Ansible | *.yml in ansible/, playbooks/ |
| Vagrant | Vagrantfile |
| CI/CD | .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, .circleci/config.yml, azure-pipelines.yml |
| Build | Makefile, Taskfile.yml, Justfile |
| Web servers | nginx.conf, nginx/*.conf, apache2.conf, .htaccess, httpd.conf, Caddyfile, traefik.yml, traefik.toml |
| Databases | prisma/schema.prisma, config/database.yml, alembic.ini |
| Env files | .env.example, .env.sample |
| Version files | .node-version, .nvmrc, .python-version, .ruby-version, .go-version, .java-version, .tool-versions, runtime.txt |
| Security | .snyk, snyk.json, .trivyignore, security.txt, renovate.json, dependabot.yml |
1b. Read discovered files and extract
From each file, extract:
- Package names and versions (direct + transitive where lock files exist)
- Base images from Dockerfiles (
FROM lines) — note the OS, runtime, and version
- System packages installed via
apt-get install, apk add, yum install
- Action versions from CI workflows (e.g.
actions/checkout@v4)
- Cloud providers from Terraform (
provider "aws", resource prefixes)
- Database types from ORMs, connection strings, Docker services
- Service names from env variable patterns (
REDIS_URL, POSTGRES_HOST, MONGO_URI, KAFKA_BROKER)
1c. Grep for framework and library patterns in code
Use Grep to detect frameworks and libraries that might not appear in
dependency files. Search source directories for these import patterns:
- Frameworks:
import express, from django, import spring, using Microsoft.AspNetCore, import React, import Vue, from angular
- Auth:
passport, jsonwebtoken, jwt, oauth, auth0, firebase-auth, keycloak
- Crypto:
bcrypt, argon2, crypto, openssl, sodium
- HTTP clients:
axios, fetch, requests, httpx, okhttp, urllib3
- Message queues:
rabbitmq, kafka, celery, bull, sidekiq, nats
- Cloud SDKs:
aws-sdk, @google-cloud, azure, boto3
1d. Compile the stack inventory
Organize everything you found into a structured inventory:
- Languages (with versions where known)
- Frameworks (with versions)
- Direct dependencies (key ones — no need to list every tiny utility)
- Databases & data stores
- Infrastructure (container images, cloud providers, orchestration)
- CI/CD (platform and notable tool versions)
- Web servers & proxies
- Security tools already in use
This inventory drives the matching in Step 3 and is shown to the user in the
final output so they can verify completeness.
Step 2 — Fetch the alert feed
Use WebFetch to retrieve https://cyberowlai.com/alerts.json.
The JSON structure:
{
"generated_at": "2026-04-23T10:00:54Z",
"sources": {
"<SOURCE_NAME>": {
"items": [
{
"title": "...",
"link": "https://...",
"description": "...",
"date": "Apr 20, 2026"
}
]
}
}
}
Sources: US-CERT, CERT-FR, MA-CERT, IBM-X-FORCE-EXCHANGE, ZERODAYINITIATIVE,
OBS-Vigilance, VulDB, HK-CERT, CA-CCS, EU-CERT (~90 alerts total).
If the fetch fails: Tell the user the feed is unavailable, suggest they
check https://cyberowlai.com/activity/ directly, and still show the detected
stack inventory so the visit isn't wasted.
Step 3 — Intelligent matching
Cross-reference every alert's title and description against the full
stack inventory. Classify matches into tiers:
HIGH — Direct dependency or component match
The alert explicitly names a package, library, or tool the project uses.
Examples:
- Alert says "jQuery 3.6 vulnerability" → project has jQuery → MATCH
- Alert says "OpenSSL" → Dockerfile installs openssl → MATCH
- Alert says "nginx" → docker-compose has nginx service → MATCH
- Alert says "PostgreSQL" → project uses PostgreSQL → MATCH
MEDIUM — Framework or platform match
The alert targets a broader platform that encompasses something in the stack.
Examples:
- Alert says "Spring Framework" → project uses Spring Boot → MATCH
- Alert says "Linux kernel" → Dockerfile uses a Linux base image → MATCH
- Alert says "Chrome/Chromium" → project uses Puppeteer or Playwright → MATCH
- Alert says "Node.js" → project is a Node app → MATCH
LOW — Category match
The alert is about a class of technology the project uses, even without a
direct name match.
Examples:
- Alert about "DNS vulnerability" → project uses a DNS library → FLAG
- Alert about "TLS/SSL" → project uses HTTPS → FLAG
- Alert about "container escape" → project uses Docker → FLAG
CRITICAL — Always flag regardless of stack
Some alerts are important enough to surface no matter what the project uses.
Flag any alert where:
- Title contains: "actively exploited", "zero-day", "0-day", "critical RCE",
"remote code execution", "supply chain", "pre-auth", "unauthenticated"
- A CVE with CVSS ≥ 9.0 is mentioned
- The alert comes from CISA's Known Exploited Vulnerabilities catalog
(look for "Known Exploited Vulnerabilities" in title or description)
Step 4 — Output format
Use this structure for the report. Keep it concise — only show alerts that
matched or are critical. Don't dump the full 90-alert feed.
## CyberOwl Security Check
Last updated: [generated_at timestamp] | [N] sources checked | [total] alerts scanned
### Alerts matching your project ([count] found)
**HIGH — Direct dependency match:**
| Alert | Source | Matched Component | Date |
|---|---|---|---|
| [Title](link) | SOURCE | component-name (where detected) | date |
**MEDIUM — Platform/framework match:**
| Alert | Source | Related To | Date |
|---|---|---|---|
| [Title](link) | SOURCE | platform (context) | date |
**LOW — Category match:**
| Alert | Source | Related To | Date |
|---|---|---|---|
| [Title](link) | SOURCE | category (context) | date |
### Critical alerts (always worth knowing)
| Alert | Source | Why Flagged | Date |
|---|---|---|---|
| [Title](link) | SOURCE | Actively exploited / Zero-day / etc. | date |
### Your detected stack
- **Languages:** ...
- **Frameworks:** ...
- **Databases:** ...
- **Infrastructure:** ...
- **CI/CD:** ...
When no direct matches are found: Skip the matching tables and show only
the "Critical alerts" section with a note: "No alerts directly matched your
detected stack, but these critical advisories are worth reviewing." Always
include the detected stack section so the user can verify nothing was missed.
Omit empty tiers. If there are no HIGH matches, don't show that table.
Same for MEDIUM and LOW.
Important notes
- Be specific about where you found each component. Don't just say
"nginx" — say "nginx (from docker-compose.yml service)" or "OpenSSL (apt-get
install in Dockerfile)". This helps the user triage.
- Don't over-match. A generic alert about "multiple vulnerabilities in
various products" with no specific technology named should not match
anything. Matching must be based on actual technology names in the alert.
- Conciseness matters. The user wants a quick answer: "Am I affected?"
Don't pad the output. If there are 0 matches and 2 critical alerts, the
report should be short.
- Show your work on the stack so the user can catch anything you missed
and re-run if needed.
