Turn scattered vulnerability announcements into traceable, deduplicated security intelligence reports that can be used for decision-making. Inputs can be a time window, technology stack, product list, SBOM, CVE/GHSA identifiers, or research articles; the output is a professional report that separates facts, inferences, and unknowns.
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, and a deduplicated vulnerability list |
| Track a technology stack or asset portfolio | Filter by product, package name, version, CPE/PURL, or SBOM | Relevant vulnerabilities, affected conditions, asset match evidence, and priority |
| Deep-read a single vulnerability or research article | Cross-check against vendor/CNA advisories 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:All enabled source records successfully returned within the specified time window. Each report must list sources, query time, failed sources, and coverage gaps, and must not claim coverage of the entire internet, undisclosed vulnerabilities, or all vendor advisories.
How Customers Use It
Provide one or more of the following inputs:
- Time window, for example "last 24 hours" or "2026-07-01 to 2026-07-22";
- Technology scope, for example Java/Spring, Linux, Kubernetes, or a specific product;
- Package name, version, CPE, PURL, dependency list, or SBOM;
- CVE/GHSA identifier, vendor advisory, or research article URL;
- Report save location; if unspecified, deliver only in the session and do not write a file.
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-skills -g -a '*' -s soia-safe-track-vulnerability-intel -y
| Dependency | Type | Installation / Configuration | What to Do If Missing |
|---|---|---|---|
| Python 3.10+ | Hard dependency | Use system Python | If collection scripts 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 the source as failed; do not call cached or old data the latest |
| NVD API key | Optional enhancement | Provide it to the process using the official NVD mechanism | Without a key, run at public rate limits, reducing the window or paging |
| GitHub authentication | Optional enhancement | Use gh auth login or short-lived process credentials |
Use public quotas when there is no authentication; if that fails, list it as a coverage gap |
Optional non-secret configuration:
~/.config/soia-skills/soia-open-skills/soia-safe/soia-safe-track-vulnerability-intel/config.yml
SOIA_SEC_VULNERABILITY_INTEL_CONFIG_FILE=<custom-config-path>
The configuration stores only 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 conditions, 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 types of reports created and the user-selected save location;
- 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 conditions, report purpose, and output location. The time window must include a time zone; asset-based reports must record the version/digest of the SBOM, lock file, 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 include at least: source receipts, deduplication statistics, first-hand evidence for each P0/P1, report generation time, and coverage gaps.
2. Collect and standardize
Run first:
python3 scripts/collect_vulnerabilities.py --days 7 --sources nvd,cisa,github
When filtering is needed, add --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 bulletins, 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 steps for evidence collection.
When sources conflict, do not vote. Prefer evidence closer to the vulnerability owner and with a more recent update time, 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 PoC;
- 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 there is already a fix, mitigation, and rollback-capable deployment path.
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 fixes, 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
Default is read-only and stateless. Only write 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 first-hand 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 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 standardization:
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; if it fails, retain the source error receipt and do not treat it as an offline test failure.