Security Posture Scorecard Generation Prompt for Repositories

This prompt is for security program managers and DevSecOps engineers who need to convert raw, structured findings from multiple security scanners into a single, repeatable security posture scorecard. The job-to-be-done is quantitative trend tracking and benchmark comparison, not initial vulnerability discovery. You should use this prompt when you already have completed outputs from secret scans, dependency audits, vulnerability remediation trackers, and configuration compliance checks. The prompt synthesizes these discrete reports into a weighted scorecard with metric breakdowns, severity distributions, and a calculated overall posture score. It is designed to be run on a regular cadence—such as weekly or per-release—so you can plot score trends over time and compare repositories against internal risk thresholds.

The ideal input is a structured JSON object containing four arrays: secret_scan_findings, dependency_vulnerabilities, remediation_metrics, and config_compliance_results. Each array should contain objects with at minimum a severity field (using a consistent scale like CRITICAL, HIGH, MEDIUM, LOW), a status field (e.g., open, in_progress, resolved), and a discovered_date or last_updated timestamp. The prompt does not perform scanning itself and will produce unreliable results if fed unstructured log output or raw tool stdout. You must pre-process scanner output into the expected schema before invoking this prompt. If your input data is incomplete—for example, you have dependency scan results but no secret scan data—you should either omit that section and accept a reduced scorecard or explicitly mark the missing category as `

status": "unavailable"` to avoid the model hallucinating metrics."

Do not use this prompt for real-time incident response or as a substitute for a SIEM. It is a periodic assessment tool, not an operational alerting system. It also should not be used to make automated gating decisions—such as blocking a production deployment—without human review of the underlying findings. The scorecard is a decision-support artifact, not a source of truth. After generating the scorecard, your next step should be to store the output in a versioned data store (e.g., a database table with a generated_at timestamp) to enable trend analysis. Avoid the temptation to tweak the prompt to inflate scores; instead, calibrate the weighting parameters in the [CONSTRAINTS] section to match your organization's actual risk appetite.

This prompt template is designed to be the core instruction set you send to a model. It expects structured inputs about a repository's security state and produces a quantitative scorecard. The template uses square-bracket placeholders like [REPOSITORY_NAME] and [SECRET_SCAN_RESULTS] that you must replace with real data from your security scanning pipeline before execution. Do not send the placeholders to the model; they are for your pre-processing logic.

codeCopy
You are a security program analyst generating a quantitative security posture scorecard for a software repository. Your output must be a single, valid JSON object conforming to the provided schema. Do not include any text outside the JSON object.

## Repository Context
- Repository Name: [REPOSITORY_NAME]
- Primary Language: [PRIMARY_LANGUAGE]
- Team Owner: [TEAM_OWNER]
- Assessment Date: [ASSESSMENT_DATE]

## Security Scan Inputs
### Secret Hygiene
[SECRET_SCAN_RESULTS]

### Dependency Freshness
[DEPENDENCY_SCAN_RESULTS]

### Vulnerability Remediation Velocity
[VULNERABILITY_REMEDIATION_DATA]

### Configuration Compliance
[CONFIGURATION_COMPLIANCE_DATA]

## Scoring Rubric
Score each category on a 0.0 to 10.0 scale, where 10.0 represents the best possible posture. Use the following guidelines:
- **Secret Hygiene**: Deduct points for each active, high-confidence secret finding. A single active high-confidence secret should cap the score at 5.0.
- **Dependency Freshness**: Score based on the percentage of dependencies with known critical or high CVEs that are older than [CRITICAL_VULNERABILITY_AGE_THRESHOLD_DAYS] days.
- **Vulnerability Remediation Velocity**: Score based on the average time-to-remediate for critical and high vulnerabilities over the last [REMEDIATION_LOOKBACK_DAYS] days, compared to a target SLA of [REMEDIATION_SLA_DAYS] days.
- **Configuration Compliance**: Score based on the percentage of configuration checks passing against the [COMPLIANCE_POLICY_NAME] policy.

## Output Schema
{
  "repository": "string",
  "assessment_date": "string (YYYY-MM-DD)",
  "overall_score": "number (0.0-10.0, weighted average of categories)",
  "score_breakdown": {
    "secret_hygiene": {
      "score": "number (0.0-10.0)",
      "finding_count": "integer",
      "top_risk": "string (brief description of the most critical finding)"
    },
    "dependency_freshness": {
      "score": "number (0.0-10.0)",
      "outdated_critical_packages": "integer",
      "oldest_cve_days": "integer"
    },
    "remediation_velocity": {
      "score": "number (0.0-10.0)",
      "average_remediation_days": "number",
      "sla_compliance_percentage": "number (0-100)"
    },
    "configuration_compliance": {
      "score": "number (0.0-10.0)",
      "passing_checks": "integer",
      "total_checks": "integer"
    }
  },
  "trend_comparison": {
    "previous_score": "number or null",
    "score_delta": "number or null",
    "key_changes": ["string (brief description of major changes)"]
  },
  "critical_actions": ["string (list of the top 3-5 most urgent remediation actions)"]
}

## Constraints
- If any scan input is missing or empty, set the corresponding category score to null and note "No data available" in the `top_risk` or relevant field.
- The `overall_score` must be a weighted average: Secret Hygiene (30%), Dependency Freshness (25%), Remediation Velocity (25%), Configuration Compliance (20%). If a category score is null, redistribute its weight proportionally among the other categories.
- For `trend_comparison`, use the provided [PREVIOUS_SCORECARD_JSON] to calculate deltas. If not provided, set `previous_score` and `score_delta` to null.
- `critical_actions` must be concrete, actionable, and ordered by risk reduction impact.

To adapt this template, start by mapping your existing security tool outputs to the four input sections. The [SECRET_SCAN_RESULTS] placeholder, for example, should be replaced with a structured summary of findings from tools like trufflehog or gitleaks, not raw logs. The scoring rubric is a starting point; you should calibrate the thresholds like [CRITICAL_VULNERABILITY_AGE_THRESHOLD_DAYS] to match your organization's risk appetite. The most critical adaptation is the Output Schema—ensure it aligns with your dashboarding or data warehouse schema to enable trend tracking over time.

The Security Posture Scorecard prompt is designed to be called programmatically, not used as a one-off chat interaction. The implementation harness should treat this prompt as a deterministic scoring function: given a structured repository context bundle, it returns a quantitative scorecard. The harness is responsible for assembling that context bundle, calling the model, validating the output schema, storing results for trend analysis, and routing anomalies for human review. This prompt is not a replacement for a SAST scanner or a CVE database—it synthesizes findings from those tools into a program-level score. The harness must therefore integrate with your existing security toolchain (e.g., dependency scanners, secret detectors, static analyzers) to populate the [REPOSITORY_CONTEXT] input with pre-processed findings, not raw source code.

Wire the prompt into a scheduled or event-driven pipeline. A typical trigger is a weekly cron job or a CI/CD pipeline completion event. The harness should: (1) Fetch the latest scan results from your secret scanner, dependency vulnerability database, SAST tool, and configuration auditor. (2) Normalize those results into the structured [REPOSITORY_CONTEXT] JSON block, including finding counts, severity distributions, remediation timelines, and policy compliance flags. (3) Call the model with the prompt template, setting temperature=0 or a very low value to maximize score consistency across runs. (4) Validate the response against the expected [OUTPUT_SCHEMA]—every metric must have a numeric score, a max score, a breakdown array, and a trend direction. If validation fails, retry once with the validation errors appended to the prompt as [CONSTRAINTS] feedback. If the second attempt fails, log the failure and alert the security engineering team; do not silently accept a malformed scorecard.

Store every generated scorecard in a time-series database or structured log store (e.g., a security_scores table with columns for repository, date, metric name, score, max score, and trend). This enables trend tracking and benchmark comparison across repositories and over time. The harness should also compute a composite score from the individual metric scores and flag any metric that drops below a configurable threshold (e.g., secret hygiene score < 70) for immediate review. For high-risk repositories or regulated environments, route scorecards with failing metrics or negative trends to a human security program manager via a ticketing system or review queue before the scorecard is published to dashboards. The prompt itself includes a [RISK_LEVEL] parameter—use this to conditionally enable the human review gate in the harness logic.

Model choice matters for consistency. Use a model with strong JSON mode and instruction-following capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) for production scorecard generation. Avoid models that are prone to hallucinating metric values or inventing findings not present in the input context. The harness should also log the full prompt, response, and validation result for each run to enable prompt observability and regression testing. Before deploying a new prompt version, run it against a golden dataset of known repository contexts with expected score ranges and verify that scores do not drift beyond an acceptable tolerance (e.g., ±5 points per metric). This prompt is a measurement tool—treat its output with the same rigor you would apply to any quantitative security metric.