Tech Version CVE Checker — Batch CVE Lookup for Your Technology Stack

Batch CVE lookup for your technology stack. Submit your entire software inventory — frameworks, libraries, languages, databases, servers — and get back a consolidated vulnerability report with CVSS scoring, severity filtering, and structured JSON output ready for CI/CD integration.

---

What does it do?

Tech Version CVE Checker takes a complete technology stack manifest — an array of software names and their installed versions — and queries the NIST National Vulnerability Database (NVD) for every known CVE affecting each component. It returns a consolidated, severity-ranked vulnerability report covering your entire technology inventory.

Unlike a per-component CVE lookup tool, this actor is designed for the specific workflow of scanning a software bill of materials (SBOM) or technology stack manifest. It accepts your stack as a structured array, performs parallel lookups across all components, and applies CVSS score filters so you see only the vulnerabilities that matter at your chosen threshold. The output is structured for direct ingestion into CI/CD pipelines, SIEM dashboards, and ticketing systems.

Built-in score filtering lets you ignore LOW-scoring vulnerabilities and focus on HIGH and CRITICAL findings — the ones that demand immediate attention.

---

Who is it for?

This actor is designed for:

• DevOps and platform engineers embedding automated vulnerability checks into CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins, CircleCI).
• Security engineers performing regular technology stack audits across development, staging, and production environments.
• SRE teams maintaining software inventory manifests and needing continuous vulnerability monitoring.
• Compliance officers generating software composition analysis (SCA) reports for regulatory compliance.
• Engineering managers tracking vulnerability debt across the organisation's technology portfolio.
• Contractors and consultants performing technology stack due diligence for client engagements.

---

Why use this?

Stack-native input format. Don't search for one piece of software at a time. Submit your full stack as an array and get a consolidated report in one API call. The input format maps directly to your existing software inventory — package.json, requirements.txt, go.mod, Gemfile, or Docker image layer analysis output.

CVSS score filtering cuts the noise. A typical stack may have hundreds of CVEs across all severity levels. Set minScore to 7.0 and focus exclusively on HIGH and CRITICAL vulnerabilities that pose genuine risk. Bypass the noise of low-scoring entries that security teams can't action anyway.

CI/CD ready. The flat JSON dataset is designed for pipeline consumption. Check the _summary row for aggregate metrics. The structured format integrates with GitHub Action annotations, GitLab merge request comments, and Slack notifications without custom parsing.

Score-based risk assessment. Every vulnerability comes with CVSS v3.1 scores, severity ratings, and published dates. The dataset can be sorted and filtered by score, making it easy to prioritise patching based on actual risk rather than publication date.

---

Input Parameters

Parameter	Type	Required	Default	Description
stack	array	Yes	—	Array of software inventory items. Each item must have software (string) and version (string) fields.
minScore	number	No	0.0	Minimum CVSS score threshold (0.0–10.0). CVEs below this score are filtered out. Set to 7.0 to show only HIGH/CRITICAL, 9.0 for CRITICAL only.
maxResults	number	No	50	Maximum CVEs to return per software/version combination (hard limit: 200).

---

Example Input

Basic stack scan:

{
  "stack": [
    { "software": "openssl", "version": "1.1.1t" },
    { "software": "nginx", "version": "1.24.0" },
    { "software": "postgresql", "version": "15.3" },
    { "software": "node", "version": "18.17.0" },
    { "software": "python", "version": "3.11.4" },
    { "software": "log4j", "version": "2.17.1" }
  ]
}

High-severity focused scan (CVSS ≥ 7.0):

{
  "stack": [
    { "software": "openssl", "version": "1.1.1w" },
    { "software": "nginx", "version": "1.25.0" },
    { "software": "redis", "version": "7.2.0" },
    { "software": "curl", "version": "8.1.2" }
  ],
  "minScore": 7.0,
  "maxResults": 20
}

---

📤 Output Format

The actor pushes each CVE as a flat dataset item via Actor.push_data(). Each vulnerability is an individual row. A final _summary row is appended with aggregate statistics.

CVE item fields

Field	Type	Description
cveId	string	CVE identifier (e.g. CVE-2023-5363)
description	string	English description of the vulnerability (truncated to 500 characters)
severity	string	CVSS base severity: NONE, LOW, MEDIUM, HIGH, CRITICAL
cvssScore	number	CVSS v3.x base score (0.0–10.0)
publishedDate	string	ISO 8601 publication date from NVD
software	string	Software name from the input stack
version	string	Version string from the input stack

Summary item fields

Field	Type	Description
_summary	boolean	Always true — distinguishes this row from CVE items
total_cves	number	Total number of CVEs found across all components
software_count	number	Number of software packages scanned
has_severe_alerts	boolean	true if any CVE has a CVSS score ≥ 9.0
severity_breakdown	object	Count of CVEs grouped by severity (e.g. {"HIGH": 3, "MEDIUM": 8})

---

Example Output

{"cveId":"CVE-2023-5363","description":"Issue in determining the validity of a certificate chain...","severity":"HIGH","cvssScore":7.5,"publishedDate":"2023-10-10T00:00:00.000","software":"openssl","version":"1.1.1t"}
{"cveId":"CVE-2023-44487","description":"HTTP/2 rapid reset attack vulnerability...","severity":"HIGH","cvssScore":7.5,"publishedDate":"2023-10-10T00:00:00.000","software":"nginx","version":"1.24.0"}
{"cveId":"CVE-2023-1234","description":"Buffer overflow in XYZ parsing...","severity":"MEDIUM","cvssScore":6.1,"publishedDate":"2023-09-15T00:00:00.000","software":"openssl","version":"1.1.1t"}
{"_summary":true,"total_cves":3,"software_count":6,"has_severe_alerts":false,"severity_breakdown":{"HIGH":2,"MEDIUM":1}}

Note: The actor pushes one JSON object per line (JSON Lines / NDJSON format). Each line is an individual dataset item. The _summary item is always the last row.

---

API Usage

cURL

# Basic stack scan
curl -X POST "https://api.apify.com/v2/acts/perryay~tech-version-cve-checker/runs" \
  -H "Content-Type: application/json" \
  -d '{
    "stack": [
      {"software": "openssl", "version": "1.1.1t"},
      {"software": "nginx", "version": "1.24.0"},
      {"software": "postgresql", "version": "15.3"}
    ]
  }'

# High-severity focused scan
curl -X POST "https://api.apify.com/v2/acts/perryay~tech-version-cve-checker/runs" \
  -H "Content-Type: application/json" \
  -d '{
    "stack": [
      {"software": "openssl", "version": "1.1.1w"},
      {"software": "nginx", "version": "1.25.0"},
      {"software": "redis", "version": "7.2.0"}
    ],
    "minScore": 7.0
  }'

Python

import requests
import json
import sys

API_TOKEN = "YOUR_API_TOKEN"
ACTOR_ID = "perryay~tech-version-cve-checker"

# Define your technology stack
stack = [
    {"software": "openssl", "version": "1.1.1t"},
    {"software": "nginx", "version": "1.24.0"},
    {"software": "postgresql", "version": "15.3"},
    {"software": "node", "version": "18.17.0"},
    {"software": "python", "version": "3.11.4"},
    {"software": "log4j", "version": "2.17.1"},
]

payload = {
    "stack": stack,
    "minScore": 7.0,
}

response = requests.post(
    f"https://api.apify.com/v2/acts/{ACTOR_ID}/runs",
    params={"token": API_TOKEN},
    json=payload
)

# Output is JSON Lines — each line is a dataset item
run_data = response.json()
print(f"Stack scan completed. Check your dataset for results.")

---

Use Cases

CI/CD vulnerability gate

Integrate the actor into your CI/CD pipeline as a deployment gating step. Whenever a build is triggered, the pipeline runs the current software stack through Tech Version CVE Checker. If any CVE exceeds your configured CVSS score threshold, the build is stopped or flagged for review. This prevents deploying known-vulnerable software into production.

Monthly stack audit

Schedule a recurring scan of your full technology stack — production, staging, and development environments. Generate a severity-ranked report and distribute it to the engineering teams responsible for each component. Track vulnerability debt over time: are you reducing your CVE count or accumulating it?

SBOM analysis

If your organisation generates Software Bill of Materials (SBOM) documents in SPDX or CycloneDX format, parse the SBOM to extract software names and versions, then submit the list to Tech Version CVE Checker. This gives you a vulnerability-annotated SBOM for compliance reporting.

Dependency upgrade planning

Before planning a major dependency upgrade cycle, run your current stack through the checker to identify which components have the most severe vulnerabilities. Prioritise upgrades based on actual risk rather than arbitrary schedules. After upgrading, re-run the checker to confirm the vulnerabilities are resolved.

M&A technology due diligence

When evaluating a target company's technology stack, run their disclosed software inventory through the checker. Get an immediate picture of the vulnerability burden you would inherit. Use the results to inform risk assessment, integration planning, and remediation budgeting.

Container image vulnerability reporting

Extract software versions from your container images (using tools like Trivy, Grype, or Docker Scout) and feed the results into Tech Version CVE Checker for a consolidated NVD-based vulnerability view that supplements your container scanner's findings.

---

FAQ

Q: How is this different from the CVE Vulnerability Lookup actor?

Tech Version CVE Checker is designed specifically for scanning multiple software components as a batch — your full technology stack. It accepts a stack array rather than individual software/version pairs, provides CVSS score filtering, and returns a _summary row with aggregate statistics. CVE Vulnerability Lookup is better suited for ad-hoc single-software queries.

Q: Can I use this in a GitHub Action?

Yes. The JSON Lines output is easy to parse in any CI runner. Each line is a complete JSON object, and the _summary row (always last) gives you aggregate metrics for pass/fail decisioning.

Q: What minScore threshold should I set for CI/CD gating?

Most teams start with 7.0 — this catches HIGH and CRITICAL vulnerabilities that genuinely matter without blocking deployments for every low-scoring finding. As your security maturity increases, you may move toward 4.0 (MEDIUM+) or keep 7.0 and add a review requirement for MEDIUM findings.

Q: How many components can I check in a single run?

The actor supports stacks of up to 30 components. This covers the vast majority of real-world technology stacks.

Q: What if one of my components isn't found in the NVD?

Components that are not indexed in the NVD return zero CVEs. This is common for very niche or proprietary software.

Q: What CVE data freshness can I expect?

The actor queries the NIST NVD API in real-time. CVEs are available as soon as NIST publishes them. There is no intermediate cache — every run hits the authoritative source.

Q: Can I export the results to a CSV or dashboard?

The JSON Lines output is compatible with any JSON-to-CSV converter, and its flat structure maps naturally to data visualisation tools like Grafana, Datadog, or custom dashboards. The _summary row provides ready-to-use aggregate metrics for dashboard ingestion.