Turn scattered vulnerability announcements into traceable, deduplicable security intelligence reports usable for decision-making. Inputs can be a time window, technology stack, product inventory, SBOM, CVE/GHSA identifiers, or research articles; the output is a professional report with facts, inferences, and unknowns separated.
Customer-readable description
What this skill can do
| Customer wants | Skill will do | Customer can see |
|---|---|---|
| Collect recent public vulnerabilities | Pull from enabled authoritative sources, normalize, deduplicate, and verify | Source coverage, success/failure counts, deduplicated vulnerability list |
| Track a certain technology stack or asset portfolio | Filter by product, package name, version, CPE/PURL, or SBOM | Related vulnerabilities, affected conditions, asset hit evidence, and priority |
| Deep-read a vulnerability or research article | Cross-check against vendor/CNA announcements and remediation notes | Technical conclusions, exploitation prerequisites, detection, remediation, and unverified items |
| Generate daily, weekly, or special reports | Organize intelligence according to a unified report contract | Management summary, P0/P1 list, item-by-item evidence, and action recommendations |
'All vulnerabilities' in this skill means:within the specified time window, all records from sources that are enabled and successfully returned. Each report must list sources, query time, failed sources, and coverage gaps; it is prohibited to claim coverage of the entire internet, undisclosed vulnerabilities, or all vendor announcements.
How customers use it
Provide one or more of the following inputs:
- Time window, e.g., 'last 24 hours', '2026-07-01 to 2026-07-22';
- Technology scope, e.g., Java/Spring, Linux, Kubernetes, or a specific product;
- Package name, version, CPE, PURL, dependency list, or SBOM;
- CVE/GHSA identifier, vendor announcement, or research article URL;
- Report save location; if unspecified, deliver only in the session and do not write files.
Example:
使用 soia-safe-track-vulnerability-intel，收集最近 7 天 Java 与 Spring 相关漏洞，
对照我的 SBOM 去重核验，输出 P0/P1 专业报告并列出来源覆盖缺口。
Dependencies and installation
Install this skill:
npx skills add soia-team/soia-open-safe-skills -g -a '*' -s soia-safe-track-vulnerability-intel -y
| Dependency | Type | Installation / configuration | What to do when missing |
|---|---|---|---|
| Python 3.10+ | Hard dependency | Use system Python | When the collection script cannot run, fall back to agent manual verification and explicitly state the degradation |
| Internet access | Hard dependency | Allow access to selected public intelligence sources | Mark source failures; do not call cached or old data the latest |
| NVD API key | Optional enhancement | Use NVD official mechanism to provide to the process | Without a key, run at public rate limits, reducing the window or pagination |
| GitHub authentication | Optional enhancement | Use gh auth login or short-lived process credentials |
Public quotas are used when there is no authentication; if they fail, list them as coverage gaps |
Optional non-secret configuration:
~/.config/soia-skills/soia-safe-track-vulnerability-intel/config.yml
SOIA_SAFE_VULNERABILITY_INTEL_CONFIG_FILE=<custom-config-path>
The configuration only stores enabled sources, the default time window, the report language, and the user-selected output location. API keys, tokens, cookies, or authorization headers must not be written into the repository, ordinary configuration, reports, or logs.
Logs and completion receipt
Each run must report at least:
- the query window, filter criteria, and asset inventory version;
- the success, failure, raw count, and failure reason for each source;
- the counts before and after deduplication, the number of missing key fields, and the number of manual verifications;
- the type of report created and the save location selected by the user;
- uncovered sources, affected versions that cannot be confirmed, and residual risk.
Workflow
1. Freeze scope and acceptance evidence
First write down: the time window, enabled sources, technical/asset filter criteria, report purpose, and output location. The time window must include a time zone; asset-based reports must record the version/digest of the SBOM, lockfile, or image. Without an asset version, only "general intelligence" can be generated, and it cannot be claimed that a production application is affected.
Acceptance must at least include: source receipts, deduplication statistics, first-hand evidence for each P0/P1, report generation time, and coverage gaps.
2. Collect and normalize
Prefer to run:
python3 scripts/collect_vulnerabilities.py --days 7 --sources nvd,cisa,github
Add when filtering is needed --keyword <term>; when structured results need to be saved, explicitly add --output <path>. When the script does not specify --output it only writes to stdout and leaves no state in the repository or current directory.
For source priority, interface boundaries, and conflict handling, see Intelligence Sources and Evidence Strategy. The recorded fields are based on Vulnerability Record Contract .
3. Deduplicate and layer facts
Merge the same vulnerability by CVE, GHSA, and other aliases; retain all source URLs and their respective update times. Do not merge based only on similar titles.
For each key conclusion, indicate:
- Confirmed: directly supported by vendor/CNA advisories, patches, official security advisories, or reviewable source code;
- Inferred: derived from version, configuration, deployment, and exposure surface, with the reasoning chain written out;
- Unknown: missing asset version, runtime configuration, patch status, or verification environment; provide the next evidence-gathering method.
When sources conflict, do not vote. Prefer evidence that is closer to the vulnerability owner and more recently updated, while retaining the conflict in the report.
4. Assess priority
CVSS is a severity input, not a production priority. Comprehensively judge:
- whether it has been confirmed by CISA KEV or the vendor as exploited in the wild;
- whether public exploit code exists, but do not download or execute weaponized PoCs;
- whether it hits real assets and reachable entry points;
- whether it is remote, requires no authentication, and can lead to RCE/privilege escalation/data leakage;
- whether fixes, mitigations, and a rollback-capable deployment path already exist.
Use the following action levels:
| Level | Determination |
|---|---|
| P0 | Already exploited in the wild, or real exposed assets meet the prerequisites for high-impact exploitation and require immediate action |
| P1 | High impact and asset hit, but the exploitation chain, exposure surface, or in-the-wild exploitation has not all been confirmed |
| P2 | Assets may be hit or the impact is limited, and it can enter the normal remediation cycle |
| P3 | Missed assets, intelligence-only observations, or insufficient evidence |
5. Generate professional report
According to professional report contract output. The management summary answers "what to do now"; the technical section must include affected/unaffected conditions, detection methods, temporary mitigations, formal remediation, verification methods, rollback, and sources.
When citing research articles, go back to vendor advisories, CNAs, patches, or official repositories for verification. Research articles can explain exploit chains but do not independently determine affected versions or remediation conclusions.
6. Save and archive
Read-only and stateless by default. Write only to the directory chosen by the customer when the customer explicitly requests saving; do not write reports, SBOMs, asset names, or internal version inventories into the skill repository. Store structured intermediate data in the user cache directory, and place temporary downloads in the OS temporary directory and clean them up after success or failure.
7. Pre-delivery verification
- All P0/P1 have at least one primary source;
- The raw count, deduplicated count, and filtered count can be reconciled;
- Every "affected" conclusion has product, version, and preconditions;
- Every remediation recommendation has a verification method, and "upgrade to the latest version" is not treated as a complete solution;
- Failed sources and unknown items are visible;
- The report contains no credentials, internal absolute paths, weaponized payloads, or unauthorized scan results.
Private information and intermediate data
- By default, everything runs locally on the customer side, and SBOMs, asset inventories, internal versions, or reports are not uploaded;
- Public intelligence queries send only the minimum necessary fields such as CVE, GHSA, package name, and public version;
- Private configuration stores only non-secret preferences, and credentials remain in the provider login store or process environment;
- Structured caches must be rebuildable and placed in the user cache directory, and temporary downloads must be placed in the OS temporary directory and cleaned up;
- Reports are written only to the location chosen by the customer when requested, and runtime data is not written into the skill repository.
Security boundaries
- This skill collects and analyzes public intelligence and does not scan, probe, or exploit production systems.
- Do not run third-party PoCs or generate weaponized exploit chains; verification uses vendor tests, minimal harmless fixtures, or isolated experimental environments.
- Do not upload customer SBOMs, asset names, internal versions, source code snippets, or reports to intelligence providers; queries should use the minimum necessary information such as package names/CVEs.
- Sending, publishing, writing remote tickets, modifying assets, or deploying mitigations requires separate authorization.
Resources
- Collection and normalization:
scripts/collect_vulnerabilities.py - Source and evidence strategy:references/source-policy.md
- Structured records:references/vulnerability-record.schema.yml
- Professional report format:references/report-contract.md
Verification
python3 scripts/collect_vulnerabilities.py --self-test
python3 scripts/collect_vulnerabilities.py --days 1 --sources cisa --max-items 20
The second item requires network access; on failure, retain the source error receipt and do not treat it as an offline test failure.