Karimhabush Cyberowl Docs .Vuepress Public Skill

---
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

1. **Discover the project's full tech stack** (dependencies, infra, frameworks)
2. **Fetch the alert feed** from `https://cyberowlai.com/alerts.json`
3. **Match alerts against the stack** using tiered confidence
4. **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.