# Security Scan

> Run a full security audit of the current codebase and produce a dated findings report saved to docs/. Use when the user says "security scan", "run security-scan", "audit this codebase for security issues", or "I need ISO 27001 evidence for this repo". Also triggers before a major release or after a significant feature is merged. Output is a markdown report saved to docs/security-scan-YYYY-MM-DD.md.

- Skill: `miguelpecegueiro/security-scan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add miguelpecegueiro/security-scan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/miguelpecegueiro/security-scan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: MiguelPecegueiro (https://skillmd.com/u/miguelpecegueiro)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/miguelpecegueiro/security-scan

---


# Security Scan

Run a full security audit of the current codebase. Produce a findings report
that serves as ISO 27001 evidence that the check was performed.

## GoConnection context

- ISO 27001 active — findings are not optional suggestions, they are compliance items
- All secrets must be in Azure Key Vault (`goconnection-keyvault`, North Europe, RBAC mode)
- Key Vault secret naming: `Section--Key` convention (maps to `Section:Key` in .NET config)
- SQL Server: `Clientes.*`, `GoConnection.*` schemas; `OCGoConnection.*` via linked server
- Deploy target: SRVGOB (IIS, Windows Server 2019) — no container runtime
- Auth: MSAL/Entra ID for internal apps, JWT for APIs, static tokens for agent iframes
- Stack: .NET 8/10 ASP.NET Core, Razor Pages, Worker Services; Python Flask (GC_Tools only)

---

## Workflow

### 1. Read before scanning

Before looking for issues, understand what the app does:
- Read README and any docs in `docs/`
- Read the entry point (Program.cs, app.py, etc.)
- Read the dependency manifest (.csproj, requirements.txt, package.json)

Do not flag things as issues if you have not understood the context.

### 2. Scan these areas in order

**A. Credentials and secrets**
- Any connection string, API key, password, token, or secret in any file
- appsettings.json, app.config, web.config, .env files
- Hardcoded values that look like secrets even in commented-out code
- Check git history awareness: flag if sensitive-looking values are present that should have been caught earlier

**B. Authentication and authorisation**
- Every HTTP endpoint — is auth enforced?
- Every SignalR hub — is auth enforced?
- Admin or privileged routes — are they restricted correctly?
- Token validation — is it present, is it correct?

**C. Input validation and injection**
- SQL built by string concatenation anywhere in the codebase
- User-controlled values reaching the filesystem (path traversal)
- User-controlled values reaching external HTTP calls (SSRF)
- Missing input validation on any public endpoint parameter

**D. Error handling and logging**
- Empty catch blocks on security-relevant operations
- PII (names, CPFs, phone numbers, emails, agent IDs) logged without masking
- Exceptions that reveal internal structure in HTTP responses (stack traces in 500s)

**E. Dependencies**
- Any dependency that is obviously outdated or has known CVEs
- Dependencies pulled from non-standard sources
- Note: deep CVE analysis is out of scope — flag obvious cases only

**F. Configuration and infrastructure**
- Config values that belong in Key Vault but are in config files
- CORS policy — is it too broad?
- HTTPS enforcement — is it present?
- Any debug or development flags that could be enabled in production

**G. ISO 27001 specific**
- Missing audit log entries for state-changing operations (create, update, delete on sensitive data)
- Missing access control on any data that contains PII
- Any data retention or deletion mechanism (or absence of one) for personal data

### 3. Write the report

Save to `docs/security-scan-YYYY-MM-DD.md`.

Use this structure:

```markdown
# Security Scan — [App Name]
**Date:** YYYY-MM-DD  
**Repo:** [repo name]  
**Scanned by:** Cursor / security-scan skill  

---

## Summary

[2–3 sentences: what was scanned, overall posture, how many findings.]

---

## Findings

### CRITICAL

| # | File | Line | Description | Recommended fix |
|---|---|---|---|---|
| C1 | path/to/file.cs | 42 | [what it is] | [what to do] |

### HIGH

| # | File | Line | Description | Recommended fix |
|---|---|---|---|---|

### MEDIUM

| # | File | Line | Description | Recommended fix |
|---|---|---|---|---|

### LOW / INFORMATIONAL

| # | File | Line | Description | Recommended fix |
|---|---|---|---|---|

---

## Clean areas

[List the areas checked where no issues were found. This section is mandatory —
it is evidence that the check was performed, not just that findings were found.]

---

## Recommended next steps

[Ordered list of the top 3–5 actions to take, by priority.]
```

---

## Severity definitions

| Severity | Definition |
|---|---|
| **Critical** | Exploitable now or exposes credentials/PII directly. Block deploy. |
| **High** | Significant risk that is likely to be exploited or cause data loss. Fix before next release. |
| **Medium** | Real issue but requires specific conditions or attacker knowledge. Fix in current sprint. |
| **Low** | Defence-in-depth or best practice gap. Fix when convenient. |

---

## Rules

- Report file path and line number for every finding — no vague "somewhere in the codebase"
- Do not reproduce credential values — reference by file and line only
- Do not suggest architectural rewrites — findings and fixes should be surgical
- Do not flag things already covered by the global Cursor rules as findings unless
  they are actually present in the code
- If unsure whether something is a real vulnerability in this context, include it
  at Medium with the uncertainty stated explicitly
- Do not skip the Clean areas section — it is ISO 27001 evidence that the check was performed
- Do not modify source files during the scan