# security-workflows

Reusable Gitea Actions workflows for security scanning across Hellion repos. One central definition that all consumer repos call via a tiny stub.

## Usage

In any consumer repo, add `.gitea/workflows/security.yml`:

```yaml
name: Security
on:
  push:
    branches: [main, master]
  pull_request:
  schedule:
    - cron: '0 6 * * 1'   # weekly Monday 06:00 UTC
  workflow_dispatch:

jobs:
  scan:
    uses: JonKazama-Hellion/security-workflows/.gitea/workflows/security-scan.yml@main
```

That is the entire stub. Five lines of `jobs:` plus the trigger config the consumer actually wants.

## What runs

| Tool | What it does |
|---|---|
| **Semgrep** (auto-config) | SAST scanning for common vulnerability patterns across C#, JavaScript, TypeScript, Python, Go and more. Pulls language-appropriate rule packs from semgrep.dev. |
| **Trivy** (filesystem scan) | Dependency vulnerability scanning against the NVD CVE database. Picks up NuGet `*.csproj`, npm `package.json`/`package-lock.json`, Dockerfiles and more. |

Both jobs run in parallel. Either failing fails the calling workflow.

## Tuning per consumer

The reusable workflow accepts two optional inputs:

```yaml
jobs:
  scan:
    uses: JonKazama-Hellion/security-workflows/.gitea/workflows/security-scan.yml@main
    with:
      severity: 'CRITICAL'         # default 'CRITICAL,HIGH'
      semgrep-config: 'p/owasp-top-ten'   # default 'auto'
```

`severity` is the Trivy threshold, `semgrep-config` swaps the rule pack (e.g. `p/owasp-top-ten`, `p/javascript`, `p/csharp`).

## Pinning

Consumers reference `@main` for rolling updates. To pin a specific commit, use the SHA: `@<sha>`. There are no tagged releases yet, the workflow API is intentionally minimal so breaking changes should be rare.