Cursor Rules Template: Node.js Secrets Scanning SaaS with GitHub Integration

Overview

Direct answer: This Cursor rules template provides a complete copyable .cursorrules configuration for building a Node.js-based secrets scanning SaaS with GitHub integration, alerts, remediation workflows, and audit trails. It targets a modern Express + PostgreSQL stack and uses Cursor AI to guide secure, compliant development.

The Cursor rules configuration defines a Node.js/Express context, architecture constraints, authentication patterns, database interactions, testing workflows, and anti-patterns to avoid. It ensures AI suggestions align with your stack and security requirements while staying actionable and copyable for your project root.

When to Use These Cursor Rules

When building a secrets scanning SaaS that integrates with GitHub via a GitHub App.
When you need automated alerts for exposed secrets and policy violations in repositories.
When implementing remediation workflows that create PRs or issue remediation tasks automatically.
When capturing and auditing user actions, scans, and remediation events for compliance and traceability.
When enforcing a secure project structure and CI/CD practices in a Node.js/Express + PostgreSQL environment.

Copyable .cursorrules Configuration

# Cursor Rules Template for Node.js Secrets Scanning SaaS (Node.js + Express + PostgreSQL)
# Framework Role & Context
Role: You are an AI assistant guiding a Node.js/Express development team building a secrets scanning SaaS with GitHub Apps integration, alerts, remediation workflows, and audit trails.
Context: Node.js 18+ environment; Express framework; PostgreSQL as the data store; GitHub App integration for repository scanning; environment-based secret handling; CI/CD automatic tests; production-grade security required.

# Code Style and Style Guides
CodeStyle: ESLint with AirBnB style; Prettier integration; enforce consistent naming, no console.log in prod, explicit return types where applicable.

# Architecture & Directory Rules
Architecture: Microservice-like structure with services: secrets-scanner, alerts, remediation, audit-trails; databases: postgres with schemas public and audit;
DirectoryRules:
  - apps/secrets-scanner
  - apps/alerts
  - apps/remediation
  - apps/audit-trails
  - libs/db
  - libs/auth
  - libs/common
  - migrations/

# Authentication & Security Rules
Auth: GitHub App installation tokens are short-lived; rotate per session; use OAuth2 for user sessions; store tokens in encrypted environment variables; never commit secrets.
Security: Enforce TLS, HSTS; rotate encryption keys; secret scanning results must never leak actual secrets in logs.

# Database and ORM patterns
Database: PostgreSQL; use node-postgres (pg) with parameterized queries; no hardcoded credentials; migrations managed via migrations/*.sql; use prepared statements for all queries.
ORM: Do not rely on a heavy ORM; prefer raw SQL in libs/db with small helper wrappers.

# Testing & Linting Workflows
Testing: Jest for unit tests; Supertest for API integration tests; coverage threshold >= 80%.
CI/CD: GitHub Actions for lint, test, build, and deployment; run lint on push; run tests on PR; run security scan steps.

# Prohibited Actions and Anti-patterns for the AI
DoNot: Hardcode secrets; log secrets; use insecure HTTP endpoints; grant excessive GitHub scopes; rely on mocks for critical security checks; bypass migrations in prod.

# Remediation & Alerts
Remediation: On a secret detection, generate remediation tasks; open PRs to rotate secrets; notify via Slack/Email; attach audit trail events.
Alerts: Configure alerts for secret exposures, policy violations, and remediation outcomes.

# Audit Trails
Audit: All actions recorded: user, action, timestamp, service, repo, PR/link, and outcome. Audit data stored in audit schema.

Recommended Project Structure

├── apps/
│   ├── secrets-scanner/
│   │   └── index.js
│   ├── alerts/
│   │   └── notifier.js
│   ├── remediation/
│   │   └── remediation-worker.js
│   └── audit-trails/
│       └── audit-log.js
├── libs/
│   ├── db/
│   │   └── client.js
│   ├── auth/
│   │   └── oauth.js
│   └── common/
│       └── utils.js
└── migrations/
    └── 20240501_init.sql

Core Engineering Principles

Security by default: never expose secrets; rotate keys; isolate credentials per service.
Observability: structured logs, tracing, and audit trails for all actions and scans.
Fail-fast and safe defaults: detailed validation, strict type checks, and early error handling.
Declarative infrastructure and repeatable deployments via migrations and CI/CD.
Minimal surface area: least privilege access to GitHub Apps and database roles.

Code Construction Rules

Use parameterized SQL for all queries; never concatenate user input into SQL strings.
All secrets must be retrieved from a secure vault; do not store in environment variables in code.
GitHub App tokens must be ephemeral; refresh before each API call requiring GitHub access.
Directory structure must follow the recommended layout; avoid cross-service interdependencies in package imports.
Unit tests must cover core security checks and integration with GitHub API mocks.

Security and Production Rules

Enforce TLS 1.2+ and HSTS across all endpoints.
Secret scanning results must not disclose actual secret values in logs or UI.
Rotate encryption keys and use environment-specific secrets management (e.g., Vault or KMS).
Implement least privilege roles for all services and GitHub App installation scopes.
Use immutable deployments and blue/green strategies for remediation rollouts.

Testing Checklist

Unit tests for scanner logic and GitHub API interactions.
Integration tests for endpoints and remediation flows using mocked GitHub events.
End-to-end tests simulating a secret exposure and remediation PR creation.
Linting and type-checking in CI; ensure 80%+ test coverage.
Security scanning in CI: secret scanning rules and dependency checks.

Common Mistakes to Avoid

Hardcoding tokens or secrets in code or config files.
Relying on a heavy ORM that complicates SQL-level security checks.
Skipping audit logging for remediation actions.
Using broad GitHub App scopes that grant excessive permissions.

Related Cursor rules templates

Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.

FAQ

What stack is this Cursor Rules Template built for?

This template targets a Node.js + Express backend with PostgreSQL, plus a GitHub App integration for secrets scanning, alerts, remediation workflows, and audit trails, designed to be dropped into a Node.js project root.

Can I adapt this for other runtimes?

Yes. The content can be adapted to other runtimes by updating framework and directory rules, authentication methods, and database access patterns while preserving the Cursor AI structure.

How are remediation tasks created?

Remediation tasks are created as PRs or issues via the remediation service, with links to scan results and audit events, enabling traceable fixes.

Where are secrets stored and rotated?

Secrets are retrieved from a vault or KMS and never stored in code. Tokens rotate per session and are stored in encrypted env vars.

How do I extend audit trails for compliance?

Add audit fields to the audit_log table and emit events for scans, remediations, and PR actions to support governance requirements.

Target User

Use Cases