zhongwei/gh-project-codeguard-rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:48:30 +08:00
commit 0f14e8d5a1
26 changed files with 2265 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,12 @@
{
"name": "codeguard-security",
"description": "Security code review skill based on Project CodeGuard's comprehensive security rules. Helps AI coding agents write secure code and prevent common vulnerabilities.",
"version": "1.0.1",
"author": {
"name": "Project CodeGuard",
"url": "https://project-codeguard.org"
},
"skills": [
"./skills"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# codeguard-security
Security code review skill based on Project CodeGuard's comprehensive security rules. Helps AI coding agents write secure code and prevent common vulnerabilities.

133
plugin.lock.json Normal file
View File

@@ -0,0 +1,133 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:project-codeguard/rules:",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "72ff0c8819cd7bda0bf293bc99d06c1c550c4294",
"treeHash": "b933161e30696020153a1f7782f3ece3a4781960e0194372a87cb97d5b3e621d",
"generatedAt": "2025-11-28T10:27:41.392327Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "codeguard-security",
"description": "Security code review skill based on Project CodeGuard's comprehensive security rules. Helps AI coding agents write secure code and prevent common vulnerabilities.",
"version": "1.0.1"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "31ea64beb526ced6b52606cfd9932dbd5a3502a49f1228aae443537ca3cbdf2c"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "83f57220abec641afc09b9771e032edbb121a40f0faf1d6377399283e9c0b169"
},
{
"path": "skills/software-security/SKILL.md",
"sha256": "718519e822e3bbcc0cc5a94c5594b047db2b1d4fbc41223079b3ff77bd1f4d93"
},
{
"path": "skills/software-security/rules/codeguard-0-safe-c-functions.md",
"sha256": "beb071ff2bfa0249f7d0b37f5e86a4810f1e31cea159c3a591f6c886032c5019"
},
{
"path": "skills/software-security/rules/codeguard-0-api-web-services.md",
"sha256": "8944c23378b22fa94c958cafc3333f475ae15afe0ca2f4fe736c368b0019f1bb"
},
{
"path": "skills/software-security/rules/codeguard-0-file-handling-and-uploads.md",
"sha256": "47574b70b87bcbf28f0a02b3de14f63028d00812d68e6f73d5709bacae53ad13"
},
{
"path": "skills/software-security/rules/codeguard-0-data-storage.md",
"sha256": "c1ee92ab9b4d74619e05206fd15e860b2ca218e4f0602f56547665b7111dfbb1"
},
{
"path": "skills/software-security/rules/codeguard-0-authorization-access-control.md",
"sha256": "7901aabd6414c9afa9a05a7f6b0cb6d7dd8d7822ebf22e1c0bddec8898b0774b"
},
{
"path": "skills/software-security/rules/codeguard-0-client-side-web-security.md",
"sha256": "c0440d72c00612580243e1c613bcfcf1fb6e6740204f3044ac3562e8f392b965"
},
{
"path": "skills/software-security/rules/codeguard-0-framework-and-languages.md",
"sha256": "00f9b99af07292d05e6f5e47518176c4bd0f0584e291a99b8539d8ab2431d1a7"
},
{
"path": "skills/software-security/rules/codeguard-0-input-validation-injection.md",
"sha256": "0afa26b315e66b0ac5c150553793cd8a01b883dd7dee0017d39ae1fb765b7f00"
},
{
"path": "skills/software-security/rules/codeguard-0-devops-ci-cd-containers.md",
"sha256": "ba949142b5dca96e7472fc9e0715b4e90dfc9576aad475a6871771ba817d779c"
},
{
"path": "skills/software-security/rules/codeguard-0-privacy-data-protection.md",
"sha256": "850bce21ee2f2c4a153a7724db441de862b09793cb4ee1a8095bca1e10a326d0"
},
{
"path": "skills/software-security/rules/codeguard-0-logging.md",
"sha256": "4970a652637b1e2755004c15dd4668c1dd82411c6faebb61620c35971a730669"
},
{
"path": "skills/software-security/rules/codeguard-1-hardcoded-credentials.md",
"sha256": "df4d1de9c57903658def4503ab9e576f3bce407a36a90dd1406ab1ea34d1a854"
},
{
"path": "skills/software-security/rules/codeguard-0-cloud-orchestration-kubernetes.md",
"sha256": "308f477f9edf90da9297019de6d14785725292612e0ff899ad43f63bd2fa575a"
},
{
"path": "skills/software-security/rules/codeguard-1-digital-certificates.md",
"sha256": "642459504b963f6f0bdb28ae44cd52b1696f957efbaa84788af22ef82ef0650f"
},
{
"path": "skills/software-security/rules/codeguard-0-authentication-mfa.md",
"sha256": "53ade8416f946ed53c9180f74245cd59c6519ea81ca6289940b9d754fbc52273"
},
{
"path": "skills/software-security/rules/codeguard-0-supply-chain-security.md",
"sha256": "2cd9aa233e9b64d7df80692692b8cc330e8adc188f0c1d5a5ccb3266724c48c0"
},
{
"path": "skills/software-security/rules/codeguard-0-iac-security.md",
"sha256": "1053ab75e9623664e6e0264b9e70b1aa42addde499a3444639a96a2464dd995f"
},
{
"path": "skills/software-security/rules/codeguard-0-additional-cryptography.md",
"sha256": "561e1ec6b9d2215b4d821dd6fabeabac8768821cec021c58c6d9fd4b9d9fafc5"
},
{
"path": "skills/software-security/rules/codeguard-0-mobile-apps.md",
"sha256": "2378f4023a16729e687e0b1940e5468950431dc79c67033e74c378a30645db85"
},
{
"path": "skills/software-security/rules/codeguard-0-session-management-and-cookies.md",
"sha256": "48818f20c6b94d37e842700db582e855293276afcf84c1e233dc1d452f0ad4b4"
},
{
"path": "skills/software-security/rules/codeguard-0-xml-and-serialization.md",
"sha256": "e0e3b8f02a35805a74813a3321e7af28326db4207bb94fa25d5b1a5fcba27a13"
},
{
"path": "skills/software-security/rules/codeguard-1-crypto-algorithms.md",
"sha256": "9b3dddf44717f1f0c652820c2f695d4b4a31f0a00a17bb3978c709de0bd42df3"
}
],
"dirSha256": "b933161e30696020153a1f7782f3ece3a4781960e0194372a87cb97d5b3e621d"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

86
skills/software-security/SKILL.md Normal file
View File

@@ -0,0 +1,86 @@
---
name: software-security
description: A software security skill that integrates with Project CodeGuard to help AI coding agents write secure code and prevent common vulnerabilities. Use this skill when writing, reviewing, or modifying code to ensure secure-by-default practices are followed.
codeguard-version: "1.0.1"
framework: "Project CodeGuard"
purpose: "Embed secure-by-default practices into AI coding workflows"
---
# Software Security Skill (Project CodeGuard)
This skill provides comprehensive security guidance to help AI coding agents generate secure code and prevent common vulnerabilities. It is based on **Project CodeGuard**, an open-source, model-agnostic security framework that embeds secure-by-default practices into AI coding workflows.
## When to Use This Skill
This skill should be activated when:
- Writing new code in any language
- Reviewing or modifying existing code
- Implementing security-sensitive features (authentication, cryptography, data handling, etc.)
- Working with user input, databases, APIs, or external services
- Configuring cloud infrastructure, CI/CD pipelines, or containers
- Handling sensitive data, credentials, or cryptographic operations
## How to Use This Skill
When writing or reviewing code:
1. Always-Apply Rules: Some rules MUST be checked on every code operation:
- `codeguard-1-hardcoded-credentials.md` - Never hardcode secrets, passwords, API keys, or tokens
- `codeguard-1-crypto-algorithms.md` - Use only modern, secure cryptographic algorithms
- `codeguard-1-digital-certificates.md` - Validate and manage digital certificates securely
2. Context-Specific Rules: Apply rules from /rules directory based on the language of the feature being implemented using the table given below:
| Language | Rule Files to Apply |
|----------|---------------------|
| c | codeguard-0-additional-cryptography.md, codeguard-0-api-web-services.md, codeguard-0-authentication-mfa.md, codeguard-0-authorization-access-control.md, codeguard-0-client-side-web-security.md, codeguard-0-data-storage.md, codeguard-0-file-handling-and-uploads.md, codeguard-0-framework-and-languages.md, codeguard-0-iac-security.md, codeguard-0-input-validation-injection.md, codeguard-0-logging.md, codeguard-0-safe-c-functions.md, codeguard-0-session-management-and-cookies.md, codeguard-0-xml-and-serialization.md |
| cpp | codeguard-0-safe-c-functions.md |
| d | codeguard-0-iac-security.md |
| docker | codeguard-0-devops-ci-cd-containers.md, codeguard-0-supply-chain-security.md |
| go | codeguard-0-additional-cryptography.md, codeguard-0-api-web-services.md, codeguard-0-authentication-mfa.md, codeguard-0-authorization-access-control.md, codeguard-0-file-handling-and-uploads.md, codeguard-0-input-validation-injection.md, codeguard-0-session-management-and-cookies.md, codeguard-0-xml-and-serialization.md |
| html | codeguard-0-client-side-web-security.md, codeguard-0-input-validation-injection.md, codeguard-0-session-management-and-cookies.md |
| java | codeguard-0-additional-cryptography.md, codeguard-0-api-web-services.md, codeguard-0-authentication-mfa.md, codeguard-0-authorization-access-control.md, codeguard-0-file-handling-and-uploads.md, codeguard-0-framework-and-languages.md, codeguard-0-input-validation-injection.md, codeguard-0-mobile-apps.md, codeguard-0-session-management-and-cookies.md, codeguard-0-xml-and-serialization.md |
| javascript | codeguard-0-additional-cryptography.md, codeguard-0-api-web-services.md, codeguard-0-authentication-mfa.md, codeguard-0-authorization-access-control.md, codeguard-0-client-side-web-security.md, codeguard-0-cloud-orchestration-kubernetes.md, codeguard-0-data-storage.md, codeguard-0-devops-ci-cd-containers.md, codeguard-0-file-handling-and-uploads.md, codeguard-0-framework-and-languages.md, codeguard-0-iac-security.md, codeguard-0-input-validation-injection.md, codeguard-0-logging.md, codeguard-0-mobile-apps.md, codeguard-0-privacy-data-protection.md, codeguard-0-session-management-and-cookies.md, codeguard-0-supply-chain-security.md |
| kotlin | codeguard-0-additional-cryptography.md, codeguard-0-authentication-mfa.md, codeguard-0-framework-and-languages.md, codeguard-0-mobile-apps.md |
| matlab | codeguard-0-additional-cryptography.md, codeguard-0-authentication-mfa.md, codeguard-0-mobile-apps.md, codeguard-0-privacy-data-protection.md |
| perl | codeguard-0-mobile-apps.md |
| php | codeguard-0-additional-cryptography.md, codeguard-0-api-web-services.md, codeguard-0-authentication-mfa.md, codeguard-0-authorization-access-control.md, codeguard-0-client-side-web-security.md, codeguard-0-file-handling-and-uploads.md, codeguard-0-framework-and-languages.md, codeguard-0-input-validation-injection.md, codeguard-0-session-management-and-cookies.md, codeguard-0-xml-and-serialization.md |
| powershell | codeguard-0-devops-ci-cd-containers.md, codeguard-0-iac-security.md, codeguard-0-input-validation-injection.md |
| python | codeguard-0-additional-cryptography.md, codeguard-0-api-web-services.md, codeguard-0-authentication-mfa.md, codeguard-0-authorization-access-control.md, codeguard-0-file-handling-and-uploads.md, codeguard-0-framework-and-languages.md, codeguard-0-input-validation-injection.md, codeguard-0-session-management-and-cookies.md, codeguard-0-xml-and-serialization.md |
| ruby | codeguard-0-additional-cryptography.md, codeguard-0-api-web-services.md, codeguard-0-authentication-mfa.md, codeguard-0-authorization-access-control.md, codeguard-0-file-handling-and-uploads.md, codeguard-0-framework-and-languages.md, codeguard-0-iac-security.md, codeguard-0-input-validation-injection.md, codeguard-0-session-management-and-cookies.md, codeguard-0-xml-and-serialization.md |
| shell | codeguard-0-devops-ci-cd-containers.md, codeguard-0-iac-security.md, codeguard-0-input-validation-injection.md |
| sql | codeguard-0-data-storage.md, codeguard-0-input-validation-injection.md |
| swift | codeguard-0-additional-cryptography.md, codeguard-0-authentication-mfa.md, codeguard-0-mobile-apps.md |
| typescript | codeguard-0-additional-cryptography.md, codeguard-0-api-web-services.md, codeguard-0-authentication-mfa.md, codeguard-0-authorization-access-control.md, codeguard-0-client-side-web-security.md, codeguard-0-file-handling-and-uploads.md, codeguard-0-framework-and-languages.md, codeguard-0-input-validation-injection.md, codeguard-0-session-management-and-cookies.md |
| vlang | codeguard-0-client-side-web-security.md |
| xml | codeguard-0-additional-cryptography.md, codeguard-0-api-web-services.md, codeguard-0-devops-ci-cd-containers.md, codeguard-0-framework-and-languages.md, codeguard-0-mobile-apps.md, codeguard-0-xml-and-serialization.md |
| yaml | codeguard-0-additional-cryptography.md, codeguard-0-api-web-services.md, codeguard-0-authorization-access-control.md, codeguard-0-cloud-orchestration-kubernetes.md, codeguard-0-data-storage.md, codeguard-0-devops-ci-cd-containers.md, codeguard-0-framework-and-languages.md, codeguard-0-iac-security.md, codeguard-0-logging.md, codeguard-0-privacy-data-protection.md, codeguard-0-supply-chain-security.md |
3. Proactive Security: Don't just avoid vulnerabilities-actively implement secure patterns:
- Use parameterized queries for database access
- Validate and sanitize all user input
- Apply least-privilege principles
- Use modern cryptographic algorithms and libraries
- Implement defense-in-depth strategies
## CodeGuard Security Rules
The security rules are available in the `rules/` directory.
### Usage Workflow
When generating or reviewing code, follow this workflow:
### 1. Initial Security Check
Before writing any code:
- Check: Will this handle credentials? → Apply codeguard-1-hardcoded-credentials
- Check: What language am I using? → Identify applicable language-specific rules
- Check: What security domains are involved? → Load relevant rule files
### 2. Code Generation
While writing code:
- Apply secure-by-default patterns from relevant Project CodeGuard rules
- Add security-relevant comments explaining choices
### 3. Security Review
After writing code:
- Review against implementation checklists in each rule
- Verify no hardcoded credentials or secrets
- Validate that all the rules have been successfully followed when applicable.
- Explain which security rules were applied
- Highlight security features implemented

71
skills/software-security/rules/codeguard-0-additional-cryptography.md Normal file
View File

@@ -0,0 +1,71 @@
---
description: Additional Cryptography guidance
languages:
- c
- go
- java
- javascript
- kotlin
- matlab
- php
- python
- ruby
- swift
- typescript
- xml
- yaml
alwaysApply: false
---
rule_id: codeguard-0-additional-cryptography
## Additional Cryptography & TLS
Apply modern, vetted cryptography for data at rest and in transit. Manage keys safely, configure TLS correctly, deploy HSTS, and consider pinning only when appropriate.
### Algorithms and Modes
- Symmetric: AES‑GCM or ChaCha20‑Poly1305 preferred. Avoid ECB. CBC/CTR only with encrypt‑then‑MAC.
- Asymmetric: RSA ≥2048 or modern ECC (Curve25519/Ed25519). Use OAEP for RSA encryption.
- Hashing: SHA‑256+ for integrity; avoid MD5/SHA‑1.
- RNG: Use CSPRNG appropriate to platform (e.g., SecureRandom, crypto.randomBytes, secrets module). Never use non‑crypto RNGs.
### Key Management
- Generate keys within validated modules (HSM/KMS) and never from passwords or predictable inputs.
- Separate keys by purpose (encryption, signing, wrapping). Rotate on compromise, cryptoperiod, or policy.
- Store keys in KMS/HSM or vault; never hardcode; avoid plain env vars. Use KEK to wrap DEKs; store separately.
- Control access to trust stores; validate updates; audit all key access and operations.
### Data at Rest
- Encrypt sensitive data; minimize stored secrets; tokenize where possible.
- Use authenticated encryption; manage nonces/IVs properly; keep salts unique per item.
- Protect backups: encrypt, restrict access, test restores, manage retention.
### TLS Configuration
- Protocols: TLS 1.3 preferred; allow TLS 1.2 only for legacy compatibility; disable TLS 1.0/1.1 and SSL. Enable TLS_FALLBACK_SCSV.
- Ciphers: prefer AEAD suites; disable NULL/EXPORT/anon. Keep libraries updated; disable compression.
- Key exchange groups: prefer x25519/secp256r1; configure secure FFDHE groups if needed.
- Certificates: 2048‑bit+ keys, SHA‑256, correct CN/SAN. Manage lifecycle and revocation (OCSP stapling).
- Application: HTTPS site‑wide; redirect HTTP→HTTPS; prevent mixed content; set cookies `Secure`.
### HSTS
- Send Strict‑Transport‑Security only over HTTPS. Phase rollout:
- Test: short max‑age (e.g., 86400) with includeSubDomains
- Prod: ≥1 year max‑age; includeSubDomains when safe
- Optional preload once mature; understand permanence and subdomain impact
### Pinning
- Avoid browser HPKP. Consider pinning only for controlled clients (e.g., mobile) and when you own both ends.
- Prefer SPKI pinning with backup pins; plan secure update channels; never allow user bypass.
- Thoroughly test rotation and failure handling; understand operational risk.
### Implementation Checklist
- AEAD everywhere; vetted libraries only; no custom crypto.
- Keys generated and stored in KMS/HSM; purpose‑scoped; rotation documented.
- TLS 1.3/1.2 with strong ciphers; compression off; OCSP stapling on.
- HSTS deployed per phased plan; mixed content eliminated.
- Pinning used only where justified, with backups and update path.
### Test Plan
- Automated config scans (e.g., SSL Labs, testssl.sh) for protocol/cipher/HSTS.
- Code review for crypto API misuse; tests for key rotation, backup/restore.
- Pinning simulations for rotation/failures if deployed.

83
skills/software-security/rules/codeguard-0-api-web-services.md Normal file
View File

@@ -0,0 +1,83 @@
---
description: API & Web services security (REST/GraphQL/SOAP), schema validation, authn/z, SSRF
languages:
- c
- go
- java
- javascript
- php
- python
- ruby
- typescript
- xml
- yaml
alwaysApply: false
---
rule_id: codeguard-0-api-web-services
## API & Web Services Security
Secure REST, GraphQL, and SOAP/WS services end‑to‑end: transport, authn/z, schema validation, SSRF controls, DoS limits, and microservice‑safe patterns.
### Transport and TLS
- HTTPS only; consider mTLS for high‑value/internal services. Validate certs (CN/SAN, revocation) and prevent mixed content.
### Authentication and Tokens
- Use standard flows (OAuth2/OIDC) for clients; avoid custom schemes. For services, use mTLS or signed service tokens.
- JWTs: pin algorithms; validate iss/aud/exp/nbf; short lifetimes; rotation; denylist on logout/revoke. Prefer opaque tokens when revocation is required and central store is available.
- API keys: scope narrowly; rate limit; monitor usage; do not use alone for sensitive operations.
### Authorization
- Enforce per‑endpoint, per‑resource checks server‑side; deny by default.
- For microservices, authorize at gateway (coarse) and service (fine) layers; propagate signed internal identity, not external tokens.
### Input and Content Handling
- Validate inputs via contracts: OpenAPI/JSON Schema, GraphQL SDL, XSD. Reject unknown fields and oversize payloads; set limits.
- Content types: enforce explicit Content‑Type/Accept; reject unsupported combinations. Harden XML parsers against XXE/expansion.
### SQL/Injection Safety in Resolvers and Handlers
- Use parameterized queries/ORM bind parameters; never concatenate user input into queries or commands.
### GraphQL‑Specific Controls
- Limit query depth and overall complexity; enforce pagination; timeouts on execution; disable introspection and IDEs in production.
- Implement field/object‑level authorization to prevent IDOR/BOLA; validate batching and rate limit per object type.
### SSRF Prevention for Outbound Calls
- Do not accept raw URLs. Validate domains/IPs using libraries; restrict to HTTP/HTTPS only (block file://, gopher://, ftp://, etc.).
- Case 1 (fixed partners): strict allow‑lists; disable redirects; network egress allow‑lists.
- Case 2 (arbitrary): block private/link‑local/localhost ranges; resolve and verify all IPs are public; require signed tokens from the target where feasible.
### SOAP/WS and XML Safety
- Validate SOAP payloads with XSD; limit message sizes; enable XML signatures/encryption where required.
- Configure parsers against XXE, entity expansion, and recursive payloads; scan attachments.
### Rate Limiting and DoS
- Apply per‑IP/user/client limits, circuit breakers, and timeouts. Use server‑side batching and caching to reduce load.
### Management Endpoints
- Do not expose over the Internet. Require strong auth (MFA), network restrictions, and separate ports/hosts.
### Testing and Assessment
- Maintain formal API definitions; drive contract tests and fuzzing from specs.
- Assess endpoints for authn/z bypass, SSRF, injection, and information leakage; log token validation failures.
### Microservices Practices
- Policy‑as‑code with embedded decision points; sidecar or library PDPs.
- Service identity via mTLS or signed tokens; never reuse external tokens internally.
- Centralized structured logging with correlation IDs; sanitize sensitive data.
### Implementation Checklist
- HTTPS/mTLS configured; certs managed; no mixed content.
- Contract validation at the edge and service; unknown fields rejected; size/time limits enforced.
- Strong authn/z per endpoint; GraphQL limits applied; introspection disabled in prod.
- SSRF protections at app and network layers; redirects disabled; allow‑lists where possible.
- Rate limiting, circuit breakers, and resilient patterns in place.
- Management endpoints isolated and strongly authenticated.
- Logs structured and privacy‑safe with correlation IDs.
### Test Plan
- Contract tests for schema adherence; fuzzing with schema‑aware tools.
- Pen tests for SSRF, IDOR/BOLA, and authz bypass; performance tests for DoS limits.
- Test all HTTP methods per endpoint; discover parameters in URL paths, headers, and structured data beyond obvious query strings.
- Automated checks for token validation and revocation behavior.

104
skills/software-security/rules/codeguard-0-authentication-mfa.md Normal file
View File

@@ -0,0 +1,104 @@
---
description: Authentication and MFA best practices (passwords, MFA, OAuth/OIDC, SAML, recovery, tokens)
languages:
- c
- go
- java
- javascript
- kotlin
- matlab
- php
- python
- ruby
- swift
- typescript
alwaysApply: false
---
rule_id: codeguard-0-authentication-mfa
## Authentication & MFA
Build a resilient, user-friendly authentication system that resists credential attacks, protects secrets, and supports strong, phishing-resistant MFA and secure recovery.
### Account Identifiers and UX
- Use non-public, random, and unique internal user identifiers. Allow login via verified email or username.
- Always return generic error messages (e.g., "Invalid username or password"). Keep timing consistent to prevent account enumeration.
- Support password managers: `<input type="password">`, allow paste, no JS blocks.
### Password Policy
- Accept passphrases and full Unicode; minimum 8 characters; avoid composition rules. Set only a reasonable maximum length (64+).
- Check new passwords against breach corpora (e.g., k‑anonymity APIs); reject breached/common passwords.
### Password Storage (Hashing)
- Hash, do not encrypt. Use slow, memory‑hard algorithms with unique per‑user salts and constant‑time comparison.
- Preferred order and parameters (tune to your hardware; target <1s on server):
- Argon2id: m=19–46 MiB, t=2–1, p=1 (or equivalent security trade‑offs)
- scrypt: N=2^17, r=8, p=1 (or equivalent)
- bcrypt (legacy only): cost ≥10, be aware of 72‑byte input limit
- PBKDF2 (FIPS): PBKDF2‑HMAC‑SHA‑256 ≥600k, or SHA‑1 ≥1.3M
- Optional pepper: store outside DB (KMS/HSM); if used, apply via HMAC or pre‑hashing. Plan for user resets if pepper rotates.
- Unicode and null bytes must be supported end‑to‑end by the library.
### Authentication Flow Hardening
- Enforce TLS for all auth endpoints and token transport; enable HSTS.
- Implement rate limits per IP, account, and globally; add proof‑of‑work or CAPTCHA only as last resort.
- Lockouts/throttling: progressive backoff; avoid permanent lockout via resets/alerts.
- Uniform responses and code paths to reduce oracle/timing signals.
### Multi‑Factor Authentication (MFA)
- Adopt phishing‑resistant factors by default for sensitive accounts: passkeys/WebAuthn (FIDO2) or hardware U2F.
- Acceptable: TOTP (app‑based), smart cards with PIN. Avoid for sensitive use: SMS/voice, email codes; never rely on security questions.
- Require MFA for: login, password/email changes, disabling MFA, privilege elevation, high‑value transactions, new devices/locations.
- Risk‑based MFA signals: new device, geo‑velocity, IP reputation, unusual time, breached credentials.
- MFA recovery: provide single‑use backup codes, encourage multiple factors, and require strong identity verification for resets.
- Handle failed MFA: offer alternative enrolled methods, notify users of failures, and log context (no secrets).
### Federation and Protocols (OAuth 2.0 / OIDC / SAML)
- Use standard protocols only; do not build your own.
- OAuth 2.0/OIDC:
- Prefer Authorization Code with PKCE for public/native apps; avoid Implicit and ROPC.
- Validate state and nonce; use exact redirect URI matching; prevent open redirects.
- Constrain tokens to audience/scope; use DPoP or mTLS for sender‑constraining when possible.
- Rotate refresh tokens; revoke on logout or risk signals.
- SAML:
- TLS 1.2+; sign responses/assertions; encrypt sensitive assertions.
- Validate issuers, InResponseTo, timestamps (NotBefore/NotOnOrAfter), Recipient; verify against trusted keys.
- Prevent XML signature wrapping with strict schema validation and hardened XPath selection.
- Keep response lifetimes short; prefer SP‑initiated flows; validate RelayState; implement replay detection.
### Tokens (JWT and Opaque)
- Prefer opaque server‑managed tokens for simplicity and revocation. If using JWTs:
- Explicitly pin algorithms; reject "none"; validate iss/aud/exp/iat/nbf; use short lifetimes and rotation.
- Store secrets/keys securely (KMS/HSM). Use strong HMAC secrets or asymmetric keys; never hardcode.
- Consider binding tokens to a client context (e.g., fingerprint hash in cookie) to reduce replay.
- Implement denylist/allowlist for revocation on logout and critical events.
### Recovery and Reset
- Return the same response for existing and non‑existing accounts (no enumeration). Normalize timing.
- Generate 32+ byte, CSPRNG tokens; single‑use; store as hashes; short expiry.
- Use HTTPS reset links to pinned, trusted domains; add referrer policy (no‑referrer) on UI.
- After reset: require re‑authentication, rotate sessions, and do not auto‑login.
- Never lock accounts due to reset attempts; rate‑limit and monitor instead.
### Administrative and Internal Accounts
- Separate admin login from public forms; enforce stronger MFA, device posture checks, IP allowlists, and step‑up auth.
- Use distinct session contexts and stricter timeouts for admin operations.
### Monitoring and Signals
- Log auth events (failures/successes, MFA enroll/verify, resets, lockouts) with stable fields and correlation IDs; never log secrets or raw tokens.
- Detect credential stuffing: high failure rates, many IPs/agents, impossible travel. Notify users of new device logins.
### Implementation Checklist
- Passwords: Argon2id (preferred) with per‑user salt, constant‑time verify; breached password checks on change/set.
- MFA: WebAuthn/passkeys or hardware tokens for high‑risk; TOTP as fallback; secure recovery with backup codes.
- Federation: Authorization Code + PKCE; strict redirect URI validation; audience/scope enforced; token rotation.
- Tokens: short‑lived, sender‑constrained where possible; revocation implemented; secrets in KMS/HSM.
- Recovery: single‑use, hashed, time‑boxed tokens; consistent responses; re‑auth required after reset; sessions rotated.
- Abuse: rate limits, throttling, and anomaly detection on auth endpoints; uniform error handling.
- Admin: isolated flows with stricter policies and device checks.
### Test Plan
- Unit/integration tests for login, MFA enroll/verify, resets, and lockouts with uniform errors.
- Protocol tests: PKCE, state/nonce, redirect URI validation, token audience/scope.
- Dynamic tests for credential stuffing resistance and token replay; validate revocation after logout and role change.

60
skills/software-security/rules/codeguard-0-authorization-access-control.md Normal file
View File

@@ -0,0 +1,60 @@
---
description: Authorization and access control (RBAC/ABAC/ReBAC, IDOR, mass assignment, transaction auth)
languages:
- c
- go
- java
- javascript
- php
- python
- ruby
- typescript
- yaml
alwaysApply: false
---
rule_id: codeguard-0-authorization-access-control
## Authorization & Access Control
Enforce least privilege and precise access decisions for every request and resource, prevent IDOR and mass assignment, and provide strong transaction authorization where necessary.
### Core Principles
1. Deny by Default: The default for any access request should be 'deny'. Explicitly grant permissions to roles or users rather than explicitly denying them. When no allow rule matches, return HTTP 403 Forbidden.
2. Principle of Least Privilege: Grant users the minimum level of access required to perform their job functions. Regularly audit permissions to ensure they are not excessive.
3. Validate Permissions on Every Request: Check authorization for every single request, regardless of source (AJAX, API, direct). Use middleware/filters to ensure consistent enforcement.
4. Prefer ABAC/ReBAC over RBAC: Use Attribute-Based Access Control (ABAC) or Relationship-Based Access Control (ReBAC) for fine-grained permissions instead of simple role-based access control.
### Systemic Controls
- Centralize authorization at service boundaries via middleware/policies/filters.
- Model permissions at the resource level (ownership/tenancy) and enforce scoping in data queries.
- Return generic 403/404 responses to avoid leaking resource existence.
- Log all denials with user, action, resource identifier (non-PII), and rationale code.
### Preventing IDOR
- Never trust user-supplied identifiers alone. Always verify access to each object instance.
- Resolve resources through user-scoped queries or server-side lookups. Example: `currentUser.projects.find(id)` instead of `Project.find(id)`.
- Use non-enumerable identifiers (UUIDs/random) as defense-in-depth. Do not rely on obscurity alone.
### Preventing Mass Assignment
- Do not bind request bodies directly to domain objects containing sensitive fields.
- Expose only safe, editable fields via DTOs. Maintain explicit allow-lists for patch/update.
- Use framework features to block-list sensitive fields if allow-listing is infeasible.
### Transaction Authorization (Step-Up)
- Require a second factor for sensitive actions (wire transfers, privilege elevation, data export). Apply What‑You‑See‑Is‑What‑You‑Sign: show critical fields for user confirmation.
- Use unique, time‑limited authorization credentials per transaction; reject on data changes mid‑flow.
- Enforce the chosen authorization method server-side; prevent client‑side downgrades.
- Protect against brute-force with throttling and complete flow restarts after failures.
### Testing and Automation
- Maintain an authorization matrix (YAML/JSON) listing endpoints/resources, roles/attributes, and expected outcomes.
- Automate integration tests that iterate the matrix, mint role tokens, and assert allow/deny results—including token expiry/revocation cases.
- Exercise negative tests: swapped IDs, downgraded roles, missing scopes, and bypass attempts.
### Implementation Checklist
- Middleware/policies enforce deny-by-default and resource checks on every endpoint.
- Query scoping ensures users only access permitted rows/objects.
- DTOs and allow-lists prevent mass assignment; sensitive fields never bindable.
- Step-up authorization in place for sensitive operations with unique, short-lived credentials.
- Authorization matrix drives CI tests; failures block merges.

112
skills/software-security/rules/codeguard-0-client-side-web-security.md Normal file
View File

@@ -0,0 +1,112 @@
---
description: Client-side web security (XSS/DOM XSS, CSP, CSRF, clickjacking, XS-Leaks, third-party JS)
languages:
- c
- html
- javascript
- php
- typescript
- vlang
alwaysApply: false
---
rule_id: codeguard-0-client-side-web-security
## Client‑side Web Security
Protect browser clients against code injection, request forgery, UI redress, cross‑site leaks, and unsafe third‑party scripts with layered, context‑aware controls.
### XSS Prevention (Context‑Aware)
- HTML context: prefer `textContent`. If HTML is required, sanitize with a vetted library (e.g., DOMPurify) and strict allow‑lists.
- Attribute context: always quote attributes and encode values.
- JavaScript context: do not build JS from untrusted strings; avoid inline event handlers; use `addEventListener`.
- URL context: validate protocol/domain and encode; block `javascript:` and data URLs where inappropriate.
- Redirects/forwards: never use user input directly for destinations; use server-side mapping (ID→URL) or validate against trusted domain allowlists.
- CSS context: allow‑list values; never inject raw style text from users.
Example sanitization:
```javascript
const clean = DOMPurify.sanitize(userHtml, {
ALLOWED_TAGS: ['b','i','p','a','ul','li'],
ALLOWED_ATTR: ['href','target','rel'],
ALLOW_DATA_ATTR: false
});
```
### DOM‑based XSS and Dangerous Sinks
- Prohibit `innerHTML`, `outerHTML`, `document.write` with untrusted data.
- Prohibit `eval`, `new Function`, string‑based `setTimeout/Interval`.
- Validate and encode data before assigning to `location` or event handler properties.
- Use strict mode and explicit variable declarations to prevent global namespace pollution from DOM clobbering.
- Adopt Trusted Types and enforce strict CSP to prevent DOM sinks exploitation.
Trusted Types + CSP:
```http
Content-Security-Policy: script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'; require-trusted-types-for 'script'
```
### Content Security Policy (CSP)
- Prefer nonce‑based or hash‑based CSP over domain allow‑lists.
- Start with Report‑Only mode; collect violations; then enforce.
- Baseline to aim for: `default-src 'self'; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; form-action 'self'; object-src 'none'; base-uri 'none'; upgrade-insecure-requests`.
### CSRF Defense
- Fix XSS first; then layer CSRF defenses.
- Use framework‑native CSRF protections and synchronizer tokens on all state‑changing requests.
- Cookie settings: `SameSite=Lax` or `Strict`; sessions `Secure` and `HttpOnly`; use `__Host-` prefix when possible.
- Validate Origin/Referer; require custom headers for API mutations in SPA token models.
- Never use GET for state changes; validate tokens on POST/PUT/DELETE/PATCH only. Enforce HTTPS for all token transmission.
### Clickjacking Defense
- Primary: `Content-Security-Policy: frame-ancestors 'none'` or a specific allow‑list.
- Fallback for legacy browsers: `X-Frame-Options: DENY` or `SAMEORIGIN`.
- Consider UX confirmations for sensitive actions when framing is required.
### Cross‑Site Leaks (XS‑Leaks) Controls
- Use `SameSite` cookies appropriately; prefer `Strict` for sensitive actions.
- Adopt Fetch Metadata protections to block suspicious cross‑site requests.
- Isolate browsing contexts: COOP/COEP and CORP where applicable.
- Disable caching and add user‑unique tokens for sensitive responses to prevent cache probing.
### Third‑Party JavaScript
- Minimize and isolate: prefer sandboxed iframes with `sandbox` and postMessage origin checks.
- Use Subresource Integrity (SRI) for external scripts and monitor for changes.
- Provide a first‑party, sanitized data layer; deny direct DOM access from tags where possible.
- Govern via tag manager controls and vendor contracts; keep libraries updated.
SRI example:
```html
<script src="https://cdn.vendor.com/app.js"
integrity="sha384-..." crossorigin="anonymous"></script>
```
### HTML5, CORS, WebSockets, Storage
- postMessage: always specify exact target origin; verify `event.origin` on receive.
- CORS: avoid `*`; allow‑list origins; validate preflights; do not rely on CORS for authz.
- WebSockets: require `wss://`, origin checks, auth, message size limits, and safe JSON parsing.
- Client storage: never store secrets in `localStorage`/`sessionStorage`; prefer HttpOnly cookies; if unavoidable, isolate via Web Workers.
- Links: add `rel="noopener noreferrer"` to external `target=_blank` links.
### HTTP Security Headers (Client Impact)
- HSTS: enforce HTTPS everywhere.
- X‑Content‑Type‑Options: `nosniff`.
- Referrer‑Policy and Permissions‑Policy: restrict sensitive signals and capabilities.
### AJAX and Safe DOM APIs
- Avoid dynamic code execution; use function callbacks, not strings.
- Build JSON with `JSON.stringify`; never via string concatenation.
- Prefer creating elements and setting `textContent`/safe attributes over raw HTML insertion.
### Implementation Checklist
- Contextual encoding/sanitization for every sink; no dangerous APIs without guards.
- Strict CSP with nonces and Trusted Types; violations monitored.
- CSRF tokens on all state‑changing requests; secure cookie attributes.
- Frame protections set; XS‑Leak mitigations enabled (Fetch Metadata, COOP/COEP/CORP).
- Third‑party JS isolated with SRI and sandbox; vetted data layer only.
- HTML5/CORS/WebSocket usage hardened; no secrets in web storage.
- Security headers enabled and validated.
### Test Plan
- Automated checks for dangerous DOM/API patterns.
- E2E tests for CSRF and clickjacking; CSP report monitoring.
- Manual probes for XS‑Leaks (frame count, timing, cache) and open redirect behavior.

34
skills/software-security/rules/codeguard-0-cloud-orchestration-kubernetes.md Normal file
View File

@@ -0,0 +1,34 @@
---
description: Kubernetes hardening (RBAC, admission policies, network policies, secrets, supply chain)
languages:
- javascript
- yaml
alwaysApply: false
---
rule_id: codeguard-0-cloud-orchestration-kubernetes
## Cloud & Orchestration (Kubernetes)
Kubernetes cluster and workload hardening: identity, policy, networking, secrets, and supply chain controls.
### Controls
- Identity & RBAC: least privilege for users and service accounts; separate namespaces; bind only needed roles.
- Policy: admission controls (OPA/Gatekeeper/Kyverno) for image sources, capabilities, root, network policies, and required labels/annotations.
- Networking: default‑deny with network policies; explicit egress allow‑lists; service identity/mTLS within mesh where applicable.
- Secrets: use KMS providers; avoid plaintext in manifests; rotate regularly; restrict secret mount paths.
- Nodes: hardened OS, auto‑updates, minimal attack surface; isolate sensitive workloads with taints/tolerations and dedicated nodes.
- Supply chain: verify image signatures; enforce provenance (SLSA/Sigstore) in admission.
### Checklist
- Namespaces per team/app; RBAC roles scoped; audit logging enabled.
- Admission policies enforce image provenance, non‑root, dropped capabilities, read‑only root FS, and network policy presence.
- Network policies in place for ingress/egress; service accounts scoped per deployment.
### Verification
- Cluster conformance and CIS benchmark scans.
- Policy tests in CI for manifests (OPA unit tests); periodic admission dry‑run.
### Incident Readiness
- Enable audit logs and centralize; restrict access to etcd; backup/restore tested.
- Define break‑glass roles with MFA and time‑bound approvals.

76
skills/software-security/rules/codeguard-0-data-storage.md Normal file
View File

@@ -0,0 +1,76 @@
---
description: Data & storage security (DB isolation, TLS, least privilege, RLS/CLS, backups, auditing)
languages:
- c
- javascript
- sql
- yaml
alwaysApply: false
---
rule_id: codeguard-0-data-storage
## Database Security Guidelines
This rule advises on securely configuring SQL and NoSQL databases to protect against data breaches and unauthorized access:
- Backend Database Protection
- Isolate database servers from other systems and limit host connections.
- Disable network (TCP) access when possible; use local socket files or named pipes.
- Configure database to bind only on localhost when appropriate.
- Restrict network port access to specific hosts with firewall rules.
- Place database server in separate DMZ isolated from application server.
- Never allow direct connections from thick clients to backend database.
- Transport Layer Security
- Configure database to only allow encrypted connections.
- Install trusted digital certificates on database servers.
- Use TLSv1.2+ with modern ciphers (AES-GCM, ChaCha20) for client connections.
- Verify digital certificate validity in client applications.
- Ensure all database traffic is encrypted, not just initial authentication.
- Secure Authentication Configuration
- Always require authentication, including from local server connections.
- Protect accounts with strong, unique passwords.
- Use dedicated accounts per application or service.
- Configure minimum required permissions only.
- Regularly review accounts and permissions.
- Remove accounts when applications are decommissioned.
- Change passwords when staff leave or compromise is suspected.
- Database Credential Storage
- Never store credentials in application source code.
- Store credentials in configuration files outside web root.
- Set appropriate file permissions for credential access.
- Never check credential files into source code repositories.
- Encrypt credential storage using built-in functionality when available.
- Use environment variables or secrets management solutions.
- Secure Permission Management
- Apply principle of least privilege to all database accounts.
- Do not use built-in root, sa, or SYS accounts.
- Do not grant administrative rights to application accounts.
- Restrict account connections to allowed hosts only.
- Use separate databases and accounts for Development, UAT, and Production.
- Grant only required permissions (SELECT, UPDATE, DELETE as needed).
- Avoid making accounts database owners to prevent privilege escalation.
- Implement table-level, column-level, and row-level permissions when needed.
- Database Configuration and Hardening
- Install required security updates and patches regularly.
- Run database services under low-privileged user accounts.
- Remove default accounts and sample databases.
- Store transaction logs on separate disk from main database files.
- Configure regular encrypted database backups with proper permissions.
- Disable unnecessary stored procedures and dangerous features.
- Implement database activity monitoring and alerting.
- Platform-Specific Hardening
- SQL Server: Disable xp_cmdshell, CLR execution, SQL Browser service, Mixed Mode Authentication (unless required).
- MySQL/MariaDB: Run mysql_secure_installation, disable FILE privilege for users.
- PostgreSQL: Follow PostgreSQL security documentation guidelines.
- MongoDB: Implement MongoDB security checklist requirements.
- Redis: Follow Redis security guide recommendations.
Summary:
Isolate database systems, enforce encrypted connections, implement strong authentication, store credentials securely using secrets management, apply least privilege permissions, harden database configurations, and maintain regular security updates and monitoring.

64
skills/software-security/rules/codeguard-0-devops-ci-cd-containers.md Normal file
View File

@@ -0,0 +1,64 @@
---
description: DevOps, CI/CD, and containers (pipeline hardening, artifacts, Docker/K8s images, virtual patching, toolchain)
languages:
- docker
- javascript
- powershell
- shell
- xml
- yaml
alwaysApply: false
---
rule_id: codeguard-0-devops-ci-cd-containers
## DevOps, CI/CD, and Containers
Secure the build, packaging, and deployment supply chain: protect pipelines and artifacts, harden containers, and use virtual patching and toolchain flags when necessary.
### CI/CD Pipeline Security
- Repos: protected branches; mandatory reviews; signed commits.
- Secrets: never hardcode; fetch at runtime from vault/KMS; mask in logs.
- Least privilege: ephemeral, isolated runners with minimal permissions.
- Security gates in CI: SAST, SCA, DAST, IaC scanning; block on criticals.
- Dependencies: pin via lockfiles; verify integrity; use private registries.
- Sign everything: commits and artifacts (containers/jars) and verify prior to deploy; adopt SLSA provenance.
### Docker and Container Hardening
- User: run as non‑root; set `USER` in Dockerfile
- Use `--security-opt=no-new-privileges` to prevent privilege escalation.
- Capabilities: `--cap-drop all` and add only what you need; never `--privileged`.
- Daemon socket: never mount `/var/run/docker.sock`
- DO NOT enable TCP Docker daemon socket (`-H tcp://0.0.0.0:XXX`) without TLS.
- Avoid `- "/var/run/docker.sock:/var/run/docker.sock"` in docker-compose files.
- Filesystems: read‑only root, tmpfs for temp write; resource limits (CPU/mem).
- Networks: avoid host network; define custom networks; limit exposed ports.
- Images: minimal base (distroless/alpine), pin tags and digests; remove package managers and tools from final image; add `HEALTHCHECK`.
- Secrets: Docker/Kubernetes secrets; never in layers/env; mount via runtime secrets.
- Scanning: scan images on build and admission; block high‑severity vulns.
### Node.js in Containers
- Deterministic builds: `npm ci --omit=dev`; pin base image with digest.
- Production env: `ENV NODE_ENV=production`.
- Non‑root: copy with correct ownership and drop to `USER node`.
- Signals: use an init (e.g., `dumb-init`) and implement graceful shutdown handlers.
- Multi‑stage builds: separate build and runtime; mount secrets via BuildKit; use `.dockerignore`.
### Virtual Patching (Temporary Mitigation)
- Use WAF/IPS/ModSecurity for immediate protection when code fixes are not yet possible.
- Prefer positive security rules (allow‑list) for accuracy; avoid exploit‑specific signatures.
- Process: prepare tooling in advance; analyze CVEs; implement patches in log‑only first, then enforce; track and retire after code fix.
### C/C++ Toolchain Hardening (when applicable)
- Compiler: `-Wall -Wextra -Wconversion`, `-fstack-protector-all`, PIE (`-fPIE`/`-pie`), `_FORTIFY_SOURCE=2`, CFI (`-fsanitize=cfi` with LTO).
- Linker: RELRO/now, noexecstack, NX/DEP and ASLR.
- Debug vs Release: enable sanitizers in debug; enable hardening flags in release; assert in debug only.
- CI checks: verify flags (`checksec`) and fail builds if protections missing.
### Implementation Checklist
- Pipeline: secrets in vault; ephemeral runners; security scans; signed artifacts with provenance.
- Containers: non‑root, least privilege, read‑only FS, resource limits; no daemon socket mounts.
- Images: minimal, pinned, scanned; healthchecks; `.dockerignore` maintained.
- Node images: `npm ci`, `NODE_ENV=production`, proper init and shutdown.
- Virtual patching: defined process; accurate rules; logs; retirement after fix.
- Native builds: hardening flags enabled and verified in CI.

75
skills/software-security/rules/codeguard-0-file-handling-and-uploads.md Normal file
View File

@@ -0,0 +1,75 @@
---
description: Secure file handling & uploads (validation, storage isolation, scanning, safe delivery)
languages:
- c
- go
- java
- javascript
- php
- python
- ruby
- typescript
alwaysApply: false
---
rule_id: codeguard-0-file-handling-and-uploads
## File Upload Security Guidelines
This rule advises on secure file upload practices to prevent malicious file attacks and protect system integrity:
- Extension Validation
- List allowed extensions only for business-critical functionality.
- Ensure input validation is applied before validating extensions.
- Avoid double extensions (e.g., `.jpg.php`) and null byte injection (e.g., `.php%00.jpg`).
- Use allowlist approach rather than denylist for file extensions.
- Validate extensions after decoding filename to prevent bypass attempts.
- Content Type and File Signature Validation
- Never trust client-supplied Content-Type headers as they can be spoofed.
- Validate file signatures (magic numbers) in conjunction with Content-Type checking.
- Implement allowlist approach for MIME types as a quick protection layer.
- Use file signature validation but not as a standalone security measure.
- Filename Security
- Generate random filenames (UUID/GUID) instead of using user-supplied names.
- If user filenames required, implement maximum length limits.
- Restrict characters to alphanumeric, hyphens, spaces, and periods only.
- Prevent leading periods (hidden files) and sequential periods (directory traversal).
- Avoid leading hyphens or spaces for safer shell script processing.
- File Content Validation
- For images, apply image rewriting techniques to destroy malicious content.
- For Microsoft documents, use Apache POI for validation.
- Avoid ZIP files due to numerous attack vectors.
- Implement manual file review in sandboxed environments when resources allow.
- Integrate antivirus scanning and Content Disarm & Reconstruct (CDR) for applicable file types.
- Storage Security
- Store files on different servers for complete segregation when possible.
- Store files outside webroot with administrative access only.
- If storing in webroot, set write-only permissions with proper access controls.
- Use application handlers that map IDs to filenames for public access.
- Consider database storage for specific use cases with DBA expertise.
- Access Control and Authentication
- Require user authentication before allowing file uploads.
- Implement proper authorization levels for file access and modification.
- Set filesystem permissions on principle of least privilege.
- Scan files before execution if execution permission is required.
- Upload and Download Limits
- Set proper file size limits for upload protection.
- Consider post-decompression size limits for compressed files.
- Implement request limits for download services to prevent DoS attacks.
- Use secure methods to calculate ZIP file sizes safely.
- Additional Security Measures
- Protect file upload endpoints from CSRF attacks.
- Keep all file processing libraries securely configured and updated.
- Implement logging and monitoring for upload activities.
- Provide user reporting mechanisms for illegal content.
- Use secure extraction methods for compressed files.
Summary:
Implement defense-in-depth for file uploads through multi-layered validation, secure storage practices, proper access controls, and comprehensive monitoring. Never rely on single validation methods and always generate safe filenames to prevent attacks.

121
skills/software-security/rules/codeguard-0-framework-and-languages.md Normal file
View File

@@ -0,0 +1,121 @@
---
description: Framework & language security guides (Django/DRF, Laravel/Symfony/Rails, .NET, Java/JAAS, Node.js, PHP config)
languages:
- c
- java
- javascript
- kotlin
- php
- python
- ruby
- typescript
- xml
- yaml
alwaysApply: false
---
rule_id: codeguard-0-framework-and-languages
## Framework & Language Guides
Apply secure‑by‑default patterns per platform. Harden configurations, use built‑in protections, and avoid common pitfalls.
### Django
- Disable DEBUG in production; keep Django and deps updated.
- Enable `SecurityMiddleware`, clickjacking middleware, MIME sniffing protection.
- Force HTTPS (`SECURE_SSL_REDIRECT`); configure HSTS; set secure cookie flags (`SESSION_COOKIE_SECURE`, `CSRF_COOKIE_SECURE`).
- CSRF: ensure `CsrfViewMiddleware` and `{% csrf_token %}` in forms; proper AJAX token handling.
- XSS: rely on template auto‑escaping; avoid `mark_safe` unless trusted; use `json_script` for JS.
- Auth: use `django.contrib.auth`; validators in `AUTH_PASSWORD_VALIDATORS`.
- Secrets: generate via `get_random_secret_key`; store in env/secrets manager.
### Django REST Framework (DRF)
- Set `DEFAULT_AUTHENTICATION_CLASSES` and restrictive `DEFAULT_PERMISSION_CLASSES`; never leave `AllowAny` for protected endpoints.
- Always call `self.check_object_permissions(request, obj)` for object‑level authz.
- Serializers: explicit `fields=[...]`; avoid `exclude` and `"__all__"`.
- Throttling: enable rate limits (and/or at gateway/WAF).
- Disable unsafe HTTP methods where not needed. Avoid raw SQL; use ORM/parameters.
### Laravel
- Production: `APP_DEBUG=false`; generate app key; secure file perms.
- Cookies/sessions: enable encryption middleware; set `http_only`, `same_site`, `secure`, short lifetimes.
- Mass assignment: use `$request->only()` / `$request->validated()`; avoid `$request->all()`.
- SQLi: use Eloquent parameterization; validate dynamic identifiers.
- XSS: rely on Blade escaping; avoid `{!! ... !!}` for untrusted data.
- File uploads: validate `file`, size, and `mimes`; sanitize filenames with `basename`.
- CSRF: ensure middleware and form tokens enabled.
### Symfony
- XSS: Twig auto‑escaping; avoid `|raw` unless trusted.
- CSRF: use `csrf_token()` and `isCsrfTokenValid()` for manual flows; Forms include tokens by default.
- SQLi: Doctrine parameterized queries; never concatenate inputs.
- Command execution: avoid `exec/shell_exec`; use Filesystem component.
- Uploads: validate with `#[File(...)]`; store outside public; unique names.
- Directory traversal: validate `realpath`/`basename` and enforce allowed roots.
- Sessions/security: configure secure cookies and authentication providers/firewalls.
### Ruby on Rails
- Avoid dangerous functions:
```ruby
eval("ruby code here")
system("os command here")
`ls -al /` # (backticks contain os command)
exec("os command here")
spawn("os command here")
open("| os command here")
Process.exec("os command here")
Process.spawn("os command here")
IO.binread("| os command here")
IO.binwrite("| os command here", "foo")
IO.foreach("| os command here") {}
IO.popen("os command here")
IO.read("| os command here")
IO.readlines("| os command here")
IO.write("| os command here", "foo")
```
- SQLi: always parameterize; use `sanitize_sql_like` for LIKE patterns.
- XSS: default auto‑escape; avoid `raw`, `html_safe` on untrusted data; use `sanitize` allow‑lists.
- Sessions: database‑backed store for sensitive apps; force HTTPS (`config.force_ssl = true`).
- Auth: use Devise or proven libraries; configure routes and protected areas.
- CSRF: `protect_from_forgery` for state‑changing actions.
- Secure redirects: validate/allow‑list targets.
- Headers/CORS: set secure defaults; configure `rack-cors` carefully.
### .NET (ASP.NET Core)
- Keep runtime and NuGet packages updated; enable SCA in CI.
- Authz: use `[Authorize]` attributes; perform server‑side checks; prevent IDOR.
- Authn/sessions: ASP.NET Identity; lockouts; cookies `HttpOnly`/`Secure`; short timeouts.
- Crypto: use PBKDF2 for passwords, AES‑GCM for encryption; DPAPI for local secrets; TLS 1.2+.
- Injection: parameterize SQL/LDAP; validate with allow‑lists.
- Config: enforce HTTPS redirects; remove version headers; set CSP/HSTS/X‑Content‑Type‑Options.
- CSRF: anti‑forgery tokens on state‑changing actions; validate on server.
### Java and JAAS
- SQL/JPA: use `PreparedStatement`/named parameters; never concatenate input.
- XSS: allow‑list validation; sanitize output with reputable libs; encode for context.
- Logging: parameterized logging to prevent log injection.
- Crypto: AES‑GCM; secure random nonces; never hardcode keys; use KMS/HSM.
- JAAS: configure `LoginModule` stanzas; implement `initialize/login/commit/abort/logout`; avoid exposing credentials; segregate public/private credentials; manage subject principals properly.
### Node.js
- Limit request sizes; validate and sanitize input; escape output.
- Avoid `eval`, `child_process.exec` with user input; use `helmet` for headers; `hpp` for parameter pollution.
- Rate limit auth endpoints; monitor event loop health; handle uncaught exceptions cleanly.
- Cookies: set `secure`, `httpOnly`, `sameSite`; set `NODE_ENV=production`.
- Keep packages updated; run `npm audit`; use security linters and ReDoS testing.
### PHP Configuration
- Production php.ini: `expose_php=Off`, log errors not display; restrict `allow_url_fopen/include`; set `open_basedir`.
- Disable dangerous functions; set session cookie flags (`Secure`, `HttpOnly`, `SameSite=Strict`); enable strict session mode.
- Constrain upload size/number; set resource limits (memory, post size, execution time).
- Use Snuffleupagus or similar for additional hardening.
### Implementation Checklist
- Use each framework’s built‑in CSRF/XSS/session protections and secure cookie flags.
- Parameterize all data access; avoid dangerous OS/exec functions with untrusted input.
- Enforce HTTPS/HSTS; set secure headers.
- Centralize secret management; never hardcode secrets; lock down debug in production.
- Validate/allow‑list redirects and dynamic identifiers.
- Keep dependencies and frameworks updated; run SCA and static analysis regularly.

86
skills/software-security/rules/codeguard-0-iac-security.md Normal file
View File

@@ -0,0 +1,86 @@
---
description: Infrastructure as Code Security
languages:
- c
- d
- javascript
- powershell
- ruby
- shell
- yaml
alwaysApply: false
---
rule_id: codeguard-0-iac-security
# Infrastructure as Code (IaC) Security
When designing cloud infrastructure and writing Infrastructure as Code (IaC) in languages like Terraform and CloudFormation, always use secure practices and defaults such as preventing public exposure and follow the principle of least privilege. Actively identify security misconfigurations and provide secure alternatives.
## Critical Security Patterns In Infrastructure as Code
### Network security
- **ALWAYS** restrict the access to remote administrative services, databases, LDAP, TACACS+, or other sensitive services. No service should be accessible from the entire Internet if it does not need to be. Instead, restrict access to a specific set of IP addresses or CIDR blocks which require access.
- Security Group and ACL inbound rules should **NEVER** allow `0.0.0.0/0` to remote administration ports (such as SSH 22, RDP 3389).
- Security Group and ACL inbound rules should **NEVER** allow `0.0.0.0/0` to database ports (such as 3306, 5432, 1433, 1521, 27017).
- Kubernetes API endpoints allow lists should **NEVER** allow `0.0.0.0/0`. EKS, AKS, GKE, and any other Kubernetes API endpoint should be restricted to an allowed list of CIDR addresses which require administrative access.
- **NEVER** expose cloud platform database services (RDS, Azure SQL, Cloud SQL) to all IP addresses `0.0.0.0/0`.
- Generally prefer private networking, such as internal VPC, VNET, VPN, or other internal transit unless public network access is required.
- **ALWAYS** enable VPC/VNET flow logs for network monitoring and security analysis.
- **ALWAYS** implement default deny rules and explicit allow rules for required traffic only.
- Generally prefer blocking egress traffic to the Internet by default. If egress is required appropriate traffic control solutions might include:
- Egress firewall or proxy with rules allowing access to specific required services.
- Egress security group (SG) or access control list (ACL) with rules allowing access to specific required IPs or CIDR blocks.
- DNS filtering to prevent access to malicious domains.
### Data protection
- **ALWAYS** configure data encryption at rest for all storage services including databases, file systems, object storage, and block storage.
- Enable encryption for cloud storage services (S3, Azure Blob, GCS buckets).
- Configure database encryption at rest for all database engines (RDS, Azure SQL, Cloud SQL, DocumentDB, etc.).
- Enable EBS/disk encryption for virtual machine storage volumes.
- **ALWAYS** configure encryption in transit for all data communications.
- Use TLS 1.2 or higher for all HTTPS/API communications.
- Configure SSL/TLS for database connections with certificate validation.
- Enable encryption for inter-service communication within VPCs/VNETs.
- Use encrypted protocols for remote access (SSH, HTTPS, secure RDP).
- **ALWAYS** implement data classification and protection controls based on sensitivity levels.
- Apply stricter encryption and access controls for PII, PHI, financial data, and intellectual property.
- Use separate encryption keys for different data classification levels.
- **ALWAYS** configure secure data retention and disposal policies.
- Define data retention periods based on regulatory and business requirements.
- Implement automated data lifecycle management with secure deletion.
- **ALWAYS** enable comprehensive data access monitoring and auditing.
- Log all data access, modification, and deletion operations.
- Monitor for unusual data access patterns and potential data exfiltration.
- Implement real-time alerting for sensitive data access violations.
- **ALWAYS** encrypt data backups.
- Encrypt all backup data using separate encryption keys from production data.
- Store backups in geographically distributed locations with appropriate access controls.
- Test backup restoration procedures regularly and verify backup integrity.
### Access control
- **NEVER** leave critical administration or data services with anonymous access (backups, storage, container registries, file shares) unless otherwise labeled as public classification or intended to be public.
- **NEVER** use wildcard permissions in IAM policies or cloud RBAC (`"Action": "*"`, `"Resource": "*"`)
- **NEVER** overprivilege service accounts with Owner/Admin roles when it is not necessary.
- **NEVER** use service API Keys and client secrets and instead use workload identity with role-based access control to eliminate the need for long-lived credentials.
- **NEVER** enable or use the legacy Instance Metadata Service version 1 (IMDSv1) in AWS.
- **NEVER** use legacy or outdated authentication methods (such as local users) when there is a more secure alternative such as OAuth.
### Container and VM images
- **NEVER** use non-hardened VM and container images.
- **ALWAYS** choose distroless or minimal container images.
- **RECOMMEND** using secure baseline virtual machine images from trusted sources.
- **RECOMMEND** using minimal distroless container images from trusted sources.
### Logging and administrative access
- **NEVER** disable administrative activity logging for sensitive services.
- **ALWAYS** enable audit logging for privileged operations.
### Secrets management
- **NEVER** hardcode secrets, passwords, API keys, or certificates directly in IaC source code.
- **ALWAYS** in Terraform mark secrets with "sensitive = true", in other IaC code use appropriate annotations or metadata to indicate sensitive values.
### Backup and data recovery
- **NEVER** create backups without encryption at rest and in transit.
- **ALWAYS** configure multi-region data storage for backups with cross-region replication.
- **NEVER** configure backups without retention policies and lifecycle management.

97
skills/software-security/rules/codeguard-0-input-validation-injection.md Normal file
View File

@@ -0,0 +1,97 @@
---
description: Input validation and injection defense (SQL/LDAP/OS), parameterization, prototype pollution
languages:
- c
- go
- html
- java
- javascript
- php
- powershell
- python
- ruby
- shell
- sql
- typescript
alwaysApply: false
---
rule_id: codeguard-0-input-validation-injection
## Input Validation & Injection Defense
Ensure untrusted input is validated and never interpreted as code. Prevent injection across SQL, LDAP, OS commands, templating, and JavaScript runtime object graphs.
### Core Strategy
- Validate early at trust boundaries with positive (allow‑list) validation and canonicalization.
- Treat all untrusted input as data, never as code. Use safe APIs that separate code from data.
- Parameterize queries/commands; escape only as last resort and context‑specific.
### Validation Playbook
- Syntactic validation: enforce format, type, ranges, and lengths for each field.
- Semantic validation: enforce business rules (e.g., start ≤ end date, enum allow‑lists).
- Normalization: canonicalize encodings before validation; validate complete strings (regex anchors ^$); beware ReDoS.
- Free‑form text: define character class allow‑lists; normalize Unicode; set length bounds.
- Files: validate by content type (magic), size caps, and safe extensions; server‑generate filenames; scan; store outside web root.
### SQL Injection Prevention
- Use prepared statements and parameterized queries for 100% of data access.
- Use bind variables for any dynamic SQL construction within stored procedures and never concatenate user input into SQL.
- Prefer least‑privilege DB users and views; never grant admin to app accounts.
- Escaping is fragile and discouraged; parameterization is the primary defense.
Example (Java PreparedStatement):
```java
String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, custname);
ResultSet results = pstmt.executeQuery( );
```
### LDAP Injection Prevention
- Always apply context‑appropriate escaping:
- DN escaping for `\ # + < > , ; " =` and leading/trailing spaces
- Filter escaping for `* ( ) \ NUL`
- Validate inputs with allow‑lists before constructing queries; use libraries that provide DN/filter encoders.
- Use least‑privilege LDAP connections with bind authentication; avoid anonymous binds for application queries.
### OS Command Injection Defense
- Prefer built‑in APIs instead of shelling out (e.g., library calls over `exec`).
- If unavoidable, use structured execution that separates command and arguments (e.g., ProcessBuilder). Do not invoke shells.
- Strictly allow‑list commands and validate arguments with allow‑list regex; exclude metacharacters (& | ; $ > < ` \ ! ' " ( ) and whitespace as needed).
- Use `--` to delimit arguments where supported to prevent option injection.
Example (Java ProcessBuilder):
```java
ProcessBuilder pb = new ProcessBuilder("TrustedCmd", "Arg1", "Arg2");
Map<String,String> env = pb.environment();
pb.directory(new File("TrustedDir"));
Process p = pb.start();
```
### Query Parameterization Guidance
- Use the platform’s parameterization features (JDBC PreparedStatement, .NET SqlCommand, Ruby ActiveRecord bind params, PHP PDO, SQLx bind, etc.).
- For stored procedures, ensure parameters are bound; never build dynamic SQL via string concatenation inside procedures.
### Prototype Pollution (JavaScript)
- Developers should use `new Set()` or `new Map()` instead of using object literals
- When objects are required, create with `Object.create(null)` or `{ __proto__: null }` to avoid inherited prototypes.
- Freeze or seal objects that should be immutable; consider Node `--disable-proto=delete` as defense‑in‑depth.
- Avoid unsafe deep merge utilities; validate keys against allow‑lists and block `__proto__`, `constructor`, `prototype`.
### Caching and Transport
- Apply `Cache-Control: no-store` on responses containing sensitive data; enforce HTTPS across data flows.
### Implementation Checklist
- Central validators: types, ranges, lengths, enums; canonicalization before checks.
- 100% parameterization coverage for SQL; dynamic identifiers via allow‑lists only.
- LDAP DN/filter escaping in use; inputs validated prior to query.
- No shell invocation for untrusted input; if unavoidable, structured exec + allow‑list + regex validation.
- JS object graph hardened: safe constructors, blocked prototype paths, safe merge utilities.
- File uploads validated by content, size, and extension; stored outside web root and scanned.
### Test Plan
- Static checks for string concatenation in queries/commands and dangerous DOM/merge sinks.
- Fuzzing for SQL/LDAP/OS injection vectors; unit tests for validator edge cases.
- Negative tests exercising blocked prototype keys and deep merge behavior.

45
skills/software-security/rules/codeguard-0-logging.md Normal file
View File

@@ -0,0 +1,45 @@
---
description: Logging & monitoring (structured telemetry, redaction, integrity, detection & alerting)
languages:
- c
- javascript
- yaml
alwaysApply: false
---
rule_id: codeguard-0-logging
## Logging & Monitoring
Produce structured, privacy‑aware telemetry that supports detection, response, and forensics without exposing secrets.
### What to Log
- Authn/authz events; admin actions; config changes; sensitive data access; input validation failures; security errors.
- Include correlation/request IDs, user/session IDs (non‑PII), source IP, user agent, timestamps (UTC, RFC3339).
### How to Log
- Structured logs (JSON) with stable field names; avoid free‑form text for critical signals.
- Sanitize all log inputs to prevent log injection (strip CR/LF/delimiters); validate data from other trust zones.
- Redact/tokenize secrets and sensitive fields; never log credentials, tokens, recovery codes, or raw session IDs.
- Ensure integrity: append‑only or WORM storage; tamper detection; centralized aggregation; access controls and retention policies.
### Detection & Alerting
- Build alerts for auth anomalies (credential stuffing patterns, impossible travel), privilege changes, excessive failures, SSRF indicators, and data exfil patterns.
- Tune thresholds; provide runbooks; ensure on‑call coverage; test alert flows.
### Storage & Protection
- Isolate log storage (separate partition/database); strict file/directory permissions; store outside web‑accessible locations.
- Synchronize time across systems; use secure protocols for transmission; implement tamper detection and monitoring.
### Privacy & Compliance
- Maintain data inventory and classification; minimize personal data in logs; honor retention and deletion policies.
- Provide mechanisms to trace and delete user‑linked log data where required by policy.
### Implementation Checklist
- JSON logging enabled; log injection sanitization active; redaction filters active; correlation IDs on all requests.
- Isolated log storage with tamper detection; centralized log pipeline with integrity protections; retention configured.
- Security alerts defined and tested; dashboards and reports in place.
### Validation
- Unit/integration tests assert presence/absence of key fields; redaction unit tests.
- Periodic audits for secret/PII leakage; tabletop exercises for incident workflows.

115
skills/software-security/rules/codeguard-0-mobile-apps.md Normal file
View File

@@ -0,0 +1,115 @@
---
description: 'Mobile app security (iOS/Android): storage, transport, code integrity, biometrics, permissions'
languages:
- java
- javascript
- kotlin
- matlab
- perl
- swift
- xml
alwaysApply: false
---
rule_id: codeguard-0-mobile-apps
## Mobile Application Security Guidelines
Essential security practices for developing secure mobile applications across iOS and Android platforms.
### Architecture and Design
Implement secure design principles from the start:
- Follow least privilege and defense in depth principles
- Use standard secure authentication protocols (OAuth2, JWT)
- Perform all authentication and authorization checks server-side
- Request only necessary permissions for app and backend services
- Establish security controls for app updates, patches, and releases
- Use only trusted and validated third-party libraries and components
### Authentication and Authorization
Never trust the client for security decisions:
- Perform authentication/authorization server-side only
- Do not store user passwords on device; use revocable access tokens
- Avoid hardcoding credentials in the mobile app
- Encrypt credentials in transmission
- Use platform-specific secure storage (iOS Keychain, Android Keystore)
- Require password complexity and avoid short PINs (4 digits)
- Implement session timeouts and remote logout functionality
- Require re-authentication for sensitive operations
- Use platform-supported biometric authentication with secure fallbacks
### Data Storage and Privacy
Protect sensitive data at rest and in transit:
- Encrypt sensitive data using platform APIs; avoid custom encryption
- Leverage hardware-based security features (Secure Enclave, Strongbox)
- Store private data on device's internal storage only
- Minimize PII collection to necessity and implement automatic expiration
- Avoid caching, logging, or background snapshots of sensitive data
- Always use HTTPS for network communications
### Network Communication
Assume all network communication is insecure:
- Use HTTPS for all network communication
- Do not override SSL certificate validation for self-signed certificates
- Use strong, industry standard cipher suites with appropriate key lengths
- Use certificates signed by trusted CA providers
- Consider certificate pinning for additional security
- Encrypt data even if sent over SSL
- Avoid sending sensitive data via SMS
### Code Quality and Integrity
Maintain application security throughout development:
- Use static analysis tools to identify vulnerabilities
- Make security a focal point during code reviews
- Keep all libraries up to date to patch known vulnerabilities
- Disable debugging in production builds
- Include code to validate integrity of application code
- Obfuscate the app binary
- Implement runtime anti-tampering controls:
- Check for debugging, hooking, or code injection
- Detect emulator or rooted/jailbroken devices
- Verify app signatures at runtime
### Platform-Specific Security
#### Android Security
- Use Android's ProGuard for code obfuscation
- Avoid storing sensitive data in SharedPreferences
- Disable backup mode to prevent sensitive data in backups
- Use Android Keystore with hardware backing (TEE or StrongBox)
- Implement Google's Play Integrity API for device and app integrity checks
#### iOS Security
- Configure Shortcuts permissions to require device unlock for sensitive actions
- Set Siri intent `requiresUserAuthentication` to true for sensitive functionality
- Implement authentication checks on deep link endpoints
- Use conditional logic to mask sensitive widget content on lock screen
- Store sensitive data in iOS Keychain, not plist files
- Use Secure Enclave for cryptographic key storage
- Implement App Attest API for app integrity validation
- Use DeviceCheck API for persistent device state tracking
### Testing and Monitoring
Validate security controls through comprehensive testing:
- Perform penetration testing including cryptographic vulnerability assessment
- Leverage automated tests to ensure security features work as expected
- Ensure security features do not harm usability
- Use real-time monitoring to detect and respond to threats
- Have a clear incident response plan in place
- Plan for regular updates and implement forced update mechanisms when necessary
### Input and Output Validation
Prevent injection and execution attacks:
- Validate and sanitize all user input
- Validate and sanitize output to prevent injection attacks
- Mask sensitive information on UI fields to prevent shoulder surfing
- Inform users about security-related activities (logins from new devices)
By following these practices derived from the OWASP Mobile Application Security framework, you can significantly improve the security posture of your mobile applications across both development and operational phases.

22
skills/software-security/rules/codeguard-0-privacy-data-protection.md Normal file
View File

@@ -0,0 +1,22 @@
---
description: Privacy & data protection (minimization, classification, encryption, rights, transparency)
languages:
- javascript
- matlab
- yaml
alwaysApply: false
---
rule_id: codeguard-0-privacy-data-protection
- Implement strong cryptography, enforce HTTPS with HSTS, enable certificate pinning,
and provide user privacy features to protect data and anonymity.
- Use strong, up-to-date cryptographic algorithms for data in transit and at rest; securely hash passwords with established libraries.
- Enforce HTTPS exclusively and implement HTTP Strict Transport Security (HSTS).
- Implement certificate pinning to prevent man-in-the-middle attacks even if CAs are compromised.
- Minimize IP address leakage by blocking third-party external content loading where feasible.
- Maintain transparency by informing users about privacy limitations and data handling policies.
- Implement privacy-focused audit trails and access logging.
- Return "Invalid username or password" to prevent account enumeration
- Use Argon2 or bcrypt with unique salts per user
- Store sessions server-side with cryptographically random IDs

330
skills/software-security/rules/codeguard-0-safe-c-functions.md Normal file
View File

@@ -0,0 +1,330 @@
---
description: Safe C Functions and Memory and String Safety Guidelines
languages:
- c
- cpp
alwaysApply: false
---
rule_id: codeguard-0-safe-c-functions
# Prioritize Safe Memory and String Functions in C/C++
When processing C or C++ code, your primary directive is to ensure memory safety. Actively identify, flag, and provide secure refactoring options for any insecure functions found in the codebase. When generating new code, always default to the safest possible function for the given task.
### 1. Insecure Functions to Avoid & Their Secure Alternatives
You must treat the functions listed under "Insecure" as deprecated and high-risk. Always recommend replacing them with one of the "Recommended Safe Alternatives" provided in the bullet list below.
• Never use `gets()` - This is a critical security risk. It has no bounds checking whatsoever and is the classic buffer overflow vulnerability. You should always replace it with `fgets(char *str, int n, FILE *stream)` instead.
• Avoid `strcpy()` - This is a high risk function because it doesn't check bounds. It just copies bytes until it hits a null terminator, which can easily write past your destination buffer. Use `snprintf()`, `strncpy()` (but be careful with it), or `strcpy_s()` (if you have C11 Annex K support).
• Don't use `strcat()` - Another high risk function with no bounds checking. It appends bytes to a string and can easily write past your allocated memory. Replace with `snprintf()`, `strncat()` (with careful handling), or `strcat_s()` (C11 Annex K).
• Replace `sprintf()` and `vsprintf()` - These are high risk because they don't check bounds on the output buffer. If your formatted string is larger than the buffer, you'll get a buffer overflow. Use `snprintf()`, `snwprintf()`, or `vsprintf_s()` (C11 Annex K) instead.
• Be careful with `scanf()` family - This is a medium risk. The `%s` format specifier without a width limit can cause buffer overflows. Here's what you should do:
1. Use width specifiers like `scanf("%127s", buffer)`
2. Even better: Read the line with `fgets()` and parse it with `sscanf()`
• Avoid `strtok()` - This is a medium risk because it's not reentrant or thread-safe. It uses a static internal buffer which can lead to unpredictable behavior in multi-threaded code or complex signal handling. Use `strtok_r()` (POSIX) or `strtok_s()` (C11 Annex K) instead.
• Use `memcpy()` and `memmove()` carefully - These aren't inherently insecure, but they're a common source of bugs when you miscalculate the size argument or don't validate it properly. Here's what you should do:
1. Double-check your size calculations
2. Prefer `memcpy_s()` (C11 Annex K) when available
3. Use `memmove()` if source and destination buffers might overlap
### 2. Actionable Implementation Guidelines
#### For New Code Generation:
- NEVER generate code that uses `gets()`, `strcpy()`, `strcat()`, or `sprintf()`.
- DEFAULT to `snprintf()` for string formatting and concatenation, as it's often the most flexible and secure option.
- DEFAULT to `fgets()` for reading string input from files or standard input.
#### For Code Analysis and Refactoring:
1. Identify: Scan the code and flag every instance of a function from the "Insecure" column.
2. Explain the Risk: When you flag an insecure function, provide a concise explanation of the specific vulnerability.
- _Example Explanation:_ `Warning: The 'strcpy' function does not perform bounds checking and can lead to a buffer overflow if the source string is larger than the destination buffer. This is a common security vulnerability.`
3. Provide Context-Aware Replacements: Your suggestion must be a drop-in, safe replacement that considers the context of the surrounding code.
#### Use Compiler Flags:
Enable these protective compiler flags to catch buffer overflow vulnerabilities at compile time and runtime:
- Stack Protection: Use `-fstack-protector-all` or `-fstack-protector-strong` to detect stack buffer overflows
- Address Sanitizer: Use `-fsanitize=address` during development to catch memory errors
- Object Size Checking (OSC): Use `-D_FORTIFY_SOURCE=2` to enable runtime checks for buffer overflows in functions like `strcpy`, `strcat`, `sprintf`, etc. This adds bounds checking to many of the unsafe functions mentioned above
- Format String Protection: Use `-Wformat -Wformat-security` to catch format string vulnerabilities
### 3. Refactoring Examples
Your suggestions should be concrete and actionable.
Example 1: Replacing `strcpy`
- Original Unsafe Code:
```
char destination[64];
strcpy(destination, source_string);
```
- Your Suggested Refactoring:
```
char destination[64];
snprintf(destination, sizeof(destination), "%s", source_string);
```
- Your Explanation: `Replaced 'strcpy' with 'snprintf' to ensure that no more than 63 characters plus a null terminator are written to the destination buffer, preventing a potential buffer overflow.`
Example 2: Correcting `strncpy` Usage
The `strncpy` function is a common but imperfect replacement. It may not null-terminate the destination buffer. If you must use it or see it used, you must enforce correct handling.
- Original (Potentially Unsafe) `strncpy`:
```
// This is unsafe if strlen(source) >= 10
char dest[10];
strncpy(dest, source, sizeof(dest));
```
- Your Corrected Suggestion:
```
char dest[10];
strncpy(dest, source, sizeof(dest) - 1);
dest[sizeof(dest) - 1] = '\0';
```
- Your Explanation: `Added an explicit null termination for 'strncpy'. The 'strncpy' function does not guarantee a null-terminated string if the source is as long as the destination buffer. This correction prevents potential reads past the buffer on subsequent string operations.`
Example 3: Securing `scanf`
- Original Unsafe Code:
```
char user_name[32];
printf("Enter your name: ");
scanf("%s", user_name);
```
- Your Suggested Refactoring:
```
char user_name[32];
printf("Enter your name: ");
if (fgets(user_name, sizeof(user_name), stdin)) {
// Optional: Remove trailing newline character from fgets
user_name[strcspn(user_name, "\n")] = 0;
}
```
- Your Explanation: `Replaced 'scanf("%s", ...)' with 'fgets()' to read user input. 'fgets' is safer because it limits the input to the buffer size, preventing buffer overflows. The original 'scanf' had no such protection.`
### Memory and String Safety Guidelines
#### Unsafe Memory Functions - FORBIDDEN
NEVER use these unsafe memory functions that don't check input parameter boundaries:
##### Banned Memory Functions:
- `memcpy()` → Use `memcpy_s()`
- `memset()` → Use `memset_s()`
- `memmove()` → Use `memmove_s()`
- `memcmp()` → Use `memcmp_s()`
- `bzero()` → Use `memset_s()`
- `memzero()` → Use `memset_s()`
##### Safe Memory Function Replacements:
```c
// Instead of: memcpy(dest, src, count);
errno_t result = memcpy_s(dest, dest_size, src, count);
if (result != 0) {
// Handle error
}
// Instead of: memset(dest, value, count);
errno_t result = memset_s(dest, dest_size, value, count);
// Instead of: memmove(dest, src, count);
errno_t result = memmove_s(dest, dest_size, src, count);
// Instead of: memcmp(s1, s2, count);
int indicator;
errno_t result = memcmp_s(s1, s1max, s2, s2max, count, &indicator);
if (result == 0) {
// indicator contains comparison result: <0, 0, or >0
}
```
#### Unsafe String Functions - FORBIDDEN
NEVER use these unsafe string functions that can cause buffer overflows:
##### Banned String Functions:
- `strstr()` → Use `strstr_s()`
- `strtok()` → Use `strtok_s()`
- `strcpy()` → Use `strcpy_s()`
- `strcmp()` → Use `strcmp_s()`
- `strlen()` → Use `strnlen_s()`
- `strcat()` → Use `strcat_s()`
- `sprintf()` → Use `snprintf()`
##### Safe String Function Replacements:
```c
// String Search
errno_t strstr_s(char *dest, rsize_t dmax, const char *src, rsize_t slen, char **substring);
// String Tokenization
char *strtok_s(char *dest, rsize_t *dmax, const char *src, char **ptr);
// String Copy
errno_t strcpy_s(char *dest, rsize_t dmax, const char *src);
// String Compare
errno_t strcmp_s(const char *dest, rsize_t dmax, const char *src, int *indicator);
// String Length (bounded)
rsize_t strnlen_s(const char *str, rsize_t strsz);
// String Concatenation
errno_t strcat_s(char *dest, rsize_t dmax, const char *src);
// Formatted String (always use size-bounded version)
int snprintf(char *s, size_t n, const char *format, ...);
```
#### Implementation Examples:
##### Safe String Copy Pattern:
```c
// Bad - unsafe
char dest[256];
strcpy(dest, src); // Buffer overflow risk!
// Good - safe
char dest[256];
errno_t result = strcpy_s(dest, sizeof(dest), src);
if (result != 0) {
// Handle error: src too long or invalid parameters
EWLC_LOG_ERROR("String copy failed: %d", result);
return ERROR;
}
```
##### Safe String Concatenation Pattern:
```c
// Bad - unsafe
char buffer[256] = "prefix_";
strcat(buffer, suffix); // Buffer overflow risk!
// Good - safe
char buffer[256] = "prefix_";
errno_t result = strcat_s(buffer, sizeof(buffer), suffix);
if (result != 0) {
EWLC_LOG_ERROR("String concatenation failed: %d", result);
return ERROR;
}
```
##### Safe Memory Copy Pattern:
```c
// Bad - unsafe
memcpy(dest, src, size); // No boundary checking!
// Good - safe
errno_t result = memcpy_s(dest, dest_max_size, src, size);
if (result != 0) {
EWLC_LOG_ERROR("Memory copy failed: %d", result);
return ERROR;
}
```
##### Safe String Tokenization Pattern:
```c
// Bad - unsafe
char *token = strtok(str, delim); // Modifies original string unsafely
// Good - safe
char *next_token = NULL;
rsize_t str_max = strnlen_s(str, MAX_STRING_SIZE);
char *token = strtok_s(str, &str_max, delim, &next_token);
while (token != NULL) {
// Process token
token = strtok_s(NULL, &str_max, delim, &next_token);
}
```
#### Memory and String Safety Code Review Checklist:
##### Pre-Code Review (Developer):
- [ ] No unsafe memory functions (`memcpy`, `memset`, `memmove`, `memcmp`, `bzero`)
- [ ] No unsafe string functions (`strcpy`, `strcat`, `strcmp`, `strlen`, `sprintf`, `strstr`, `strtok`)
- [ ] All memory operations use `*_s()` variants with proper size parameters
- [ ] Buffer sizes are correctly calculated using `sizeof()` or known limits
- [ ] No hardcoded buffer sizes that could change
##### Code Review (Reviewer):
- [ ] Memory Safety: Verify all memory operations use safe variants
- [ ] Buffer Bounds: Confirm destination buffer sizes are properly specified
- [ ] Error Handling: Check that all `errno_t` return values are handled
- [ ] Size Parameters: Validate that `rsize_t dmax` parameters are correct
- [ ] String Termination: Ensure strings are properly null-terminated
- [ ] Length Validation: Check that source string lengths are validated before operations
##### Static Analysis Integration:
- [ ] Enable compiler warnings for unsafe function usage
- [ ] Use static analysis tools to detect unsafe function calls
- [ ] Configure build system to treat unsafe function warnings as errors
- [ ] Add pre-commit hooks to scan for banned functions
#### Common Pitfalls and Solutions:
##### Pitfall 1: Wrong Size Parameter
```c
// Wrong - using source size instead of destination size
strcpy_s(dest, strlen(src), src); // WRONG!
// Correct - using destination buffer size
strcpy_s(dest, sizeof(dest), src); // CORRECT
```
##### Pitfall 2: Ignoring Return Values
```c
// Wrong - ignoring potential errors
strcpy_s(dest, sizeof(dest), src); // Error not checked
// Correct - checking return value
if (strcpy_s(dest, sizeof(dest), src) != 0) {
// Handle error appropriately
}
```
##### Pitfall 3: Using sizeof() on Pointers
```c
// Wrong - sizeof pointer, not buffer
void func(char *buffer) {
strcpy_s(buffer, sizeof(buffer), src); // sizeof(char*) = 8!
}
// Correct - pass buffer size as parameter
void func(char *buffer, size_t buffer_size) {
strcpy_s(buffer, buffer_size, src);
}
```
You must always explain how this rule was applied and why it was applied.

79
skills/software-security/rules/codeguard-0-session-management-and-cookies.md Normal file
View File

@@ -0,0 +1,79 @@
---
description: Session management and secure cookies (rotation, fixation, timeouts, theft detection)
languages:
- c
- go
- html
- java
- javascript
- php
- python
- ruby
- typescript
alwaysApply: false
---
rule_id: codeguard-0-session-management-and-cookies
## Session Management & Cookies
Implement robust, attack-resistant session handling that prevents fixation, hijacking, and theft while maintaining usability.
### Session ID Generation and Properties
- Generate session IDs with a CSPRNG; ≥64 bits of entropy (prefer 128+). Opaque, unguessable, and free of meaning.
- Use generic cookie names (e.g., `id`) rather than framework defaults. Reject any incoming ID not created by the server.
- Store all session data server-side; never embed PII or privileges in the token. If sensitive, encrypt server-side session store at rest.
### Cookie Security Configuration
- Set `Secure`, `HttpOnly`, `SameSite=Strict` (or `Lax` if necessary for flows) on session cookies.
- Scope cookies narrowly with `Path` and `Domain`. Avoid cross-subdomain exposure.
- Prefer non-persistent session cookies (no Expires/Max-Age). Require full HTTPS; enable HSTS site-wide.
Example header:
```
Set-Cookie: id=<opaque>; Secure; HttpOnly; SameSite=Strict; Path=/
```
### Session Lifecycle and Rotation
- Create sessions only server-side; treat provided IDs as untrusted input.
- Regenerate session ID on authentication, password changes, and any privilege elevation. Invalidate the prior ID.
- Use distinct pre‑auth and post‑auth cookie names if framework patterns require it.
### Expiration and Logout
- Idle timeout: 2–5 minutes for high-value, 15–30 minutes for lower risk. Absolute timeout: 4–8 hours.
- Enforce timeouts server-side. Provide a visible logout button that fully invalidates the server session and clears the cookie client-side.
### Transport and Caching
- Enforce HTTPS for the entire session journey. Never mix HTTP/HTTPS in one session.
- Send `Cache-Control: no-store` on responses containing session identifiers or sensitive data.
### Cookie Theft Detection and Response
- Fingerprint session context server-side at establishment (IP, User-Agent, Accept-Language, relevant `sec-ch-ua` where available).
- Compare incoming requests to the stored fingerprint, allowing for benign drift (e.g., subnet changes, UA updates).
- Risk-based responses:
- High risk: require re-authentication; rotate session ID.
- Medium risk: step-up verification (challenge); rotate session ID.
- Low risk: log suspicious activity.
- Always regenerate the session ID when potential hijacking is detected.
### Client-Side Storage
- Do not store session tokens in `localStorage`/`sessionStorage` due to XSS risk. Prefer HttpOnly cookies for transport.
- If client-side storage is unavoidable for non-session secrets, isolate via Web Workers and never expose in page context.
### Framework and Multi-Cookie Scenarios
- Prefer built-in session frameworks; keep them updated and hardened.
- Validate relationships when multiple cookies participate in session state; avoid same cookie names across paths/domains.
### Monitoring and Telemetry
- Log session lifecycle events (creation, rotation, termination) using salted hashes of the session ID, not raw values.
- Monitor for brute force of session IDs and anomalous concurrent usage.
### Implementation Checklist
1) CSPRNG session IDs (≥64 bits entropy), opaque and server-issued only.
2) Cookie flags: `Secure`, `HttpOnly`, `SameSite` set; tight domain/path.
3) HTTPS-only with HSTS; no mixed content.
4) Regenerate IDs on auth and privilege changes; invalidate old IDs.
5) Idle and absolute timeouts enforced server-side; full logout implemented.
6) `Cache-Control: no-store` for sensitive responses.
7) Server-side fingerprinting and risk-based responses to anomalies.
8) No client storage of session tokens; framework defaults hardened.

50
skills/software-security/rules/codeguard-0-supply-chain-security.md Normal file
View File

@@ -0,0 +1,50 @@
---
description: Dependency & supply chain security (pinning, SBOM, provenance, integrity, private registries)
languages:
- docker
- javascript
- yaml
alwaysApply: false
---
rule_id: codeguard-0-supply-chain-security
## Dependency & Supply Chain Security
Control third‑party risk across ecosystems, from selection and pinning to provenance, scanning, and rapid response.
### Policy and Governance
- Maintain allow‑listed registries and scopes; disallow direct installs from untrusted sources.
- Require lockfiles and version pinning; prefer digest pinning for images and vendored assets.
- Generate SBOMs for apps/images; store with artifacts; attest provenance (SLSA, Sigstore).
### Package Hygiene (npm focus applicable to others)
- Regularly audit (`npm audit`, ecosystem SCA) and patch; enforce SLAs by severity.
- Use deterministic builds: `npm ci` (not `npm install`) in CI/CD; maintain lockfile consistency.
- Avoid install scripts that execute on install when possible; review for risk.
- Use `.npmrc` to scope private registries; avoid wildcard registries; enable integrity verification.
- Enable account 2FA for publishing
### Development Practices
- Minimize dependency footprint; remove unused packages; prefer stdlib/first‑party for trivial tasks.
- Protect against typosquatting and protestware: pin maintainers, monitor releases, and use provenance checks.
- Hermetic builds: no network in compile/packaging stages unless required; cache with authenticity checks.
### CI/CD Integration
- SCA, SAST, IaC scans in gates; fail on criticals; require approvals for overrides with compensating controls.
- Sign artifacts; verify signatures at deploy; enforce policy in admission.
### Vulnerability Management
- For patched vulnerabilities: test and deploy updates; document any API breaking changes.
- For unpatched vulnerabilities: implement compensating controls (input validation, wrappers) based on CVE type; prefer direct dependency fixes over transitive workarounds.
- Document risk decisions; escalate acceptance to appropriate authority with business justification.
### Incident Response
- Maintain rapid rollback; isolate compromised packages; throttle rollouts; notify stakeholders.
- Monitor threat intel feeds (e.g., npm advisories); auto‑open tickets for critical CVEs.
### Implementation Checklist
- Lockfiles present; integrity checks on; private registries configured.
- SBOM + provenance stored; signatures verified pre‑deploy.
- Automated dependency updates with tests and review gates.
- High‑sev vulns remediated within SLA or mitigated and documented.

109
skills/software-security/rules/codeguard-0-xml-and-serialization.md Normal file
View File

@@ -0,0 +1,109 @@
---
description: XML security and safe deserialization (DTD/XXE hardening, schema validation, no unsafe native deserialization)
languages:
- c
- go
- java
- php
- python
- ruby
- xml
alwaysApply: false
---
rule_id: codeguard-0-xml-and-serialization
## XML & Serialization Hardening
Secure parsing and processing of XML and serialized data; prevent XXE, entity expansion, SSRF, DoS, and unsafe deserialization across platforms.
### XML Parser Hardening
- Disable DTDs and external entities by default; reject DOCTYPE declarations.
- Validate strictly against local, trusted XSDs; set explicit limits (size, depth, element counts).
- Sandbox or block resolver access; no network fetches during parsing; monitor for unexpected DNS activity.
#### Java
General principle:
```java
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
```
Disabling DTDs protects against XXE and Billion Laughs attacks. If DTDs cannot be disabled, disable external entities using parser-specific methods.
### Java
Java parsers have XXE enabled by default.
DocumentBuilderFactory/SAXParserFactory/DOM4J:
```java
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
String FEATURE = null;
try {
// PRIMARY defense - disallow DTDs completely
FEATURE = "http://apache.org/xml/features/disallow-doctype-decl";
dbf.setFeature(FEATURE, true);
dbf.setXIncludeAware(false);
} catch (ParserConfigurationException e) {
logger.info("ParserConfigurationException was thrown. The feature '" + FEATURE
+ "' is not supported by your XML processor.");
}
```
If DTDs cannot be completely disabled:
```java
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
String[] featuresToDisable = {
"http://xml.org/sax/features/external-general-entities",
"http://xml.org/sax/features/external-parameter-entities",
"http://apache.org/xml/features/nonvalidating/load-external-dtd"
};
for (String feature : featuresToDisable) {
try {
dbf.setFeature(feature, false);
} catch (ParserConfigurationException e) {
logger.info("ParserConfigurationException was thrown. The feature '" + feature
+ "' is probably not supported by your XML processor.");
}
}
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);
dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
```
#### .NET
```csharp
var settings = new XmlReaderSettings { DtdProcessing = DtdProcessing.Prohibit, XmlResolver = null };
var reader = XmlReader.Create(stream, settings);
```
#### Python
```python
from defusedxml import ElementTree as ET
ET.parse('file.xml')
# or lxml
from lxml import etree
parser = etree.XMLParser(resolve_entities=False, no_network=True)
tree = etree.parse('filename.xml', parser)
```
### Secure XSLT/Transformer Usage
- Set `ACCESS_EXTERNAL_DTD` and `ACCESS_EXTERNAL_STYLESHEET` to empty; avoid loading remote resources.
### Deserialization Safety
- Never deserialize untrusted native objects. Prefer JSON with schema validation.
- Enforce size/structure limits before parsing. Reject polymorphic types unless strictly allow‑listed.
- Language specifics:
- PHP: avoid `unserialize()`; use `json_decode()`.
- Python: avoid `pickle` and unsafe YAML (`yaml.safe_load` only).
- Java: override `ObjectInputStream#resolveClass` to allow‑list; avoid enabling default typing in Jackson; use XStream allow‑lists.
- .NET: avoid `BinaryFormatter`; prefer `DataContractSerializer` or `System.Text.Json` with `TypeNameHandling=None` for JSON.NET.
- Sign and verify serialized payloads where applicable; log and alert on deserialization failures and anomalies.
### Implementation Checklist
- DTDs off; external entities disabled; strict schema validation; parser limits set.
- No network access during parsing; resolvers restricted; auditing in place.
- No unsafe native deserialization; strict allow‑listing and schema validation for supported formats.
- Regular library updates and tests with XXE/deserialization payloads.

134
skills/software-security/rules/codeguard-1-crypto-algorithms.md Normal file
View File

@@ -0,0 +1,134 @@
---
description: Cryptographic Security Guidelines
alwaysApply: true
---
rule_id: codeguard-1-crypto-algorithms
# Cryptographic Security Guidelines
## Banned (Insecure) Algorithms
The following algorithms are known to be broken or fundamentally insecure. **NEVER** generate or use code with these algorithms.
Examples:
* Hash: `MD2`, `MD4`, `MD5`, `SHA-0`
* Symmetric: `RC2`, `RC4`, `Blowfish`, `DES`, `3DES`
* Key Exchange: Static RSA, Anonymous Diffie-Hellman
* Classical: `Vigenère`
## Deprecated (Legacy/Weak) Algorithms
The following algorithms are not outright broken, but have known weaknesses, or are considered obsolete. **NEVER** generate or use code with these algorithms.
Examples:
* Hash: `SHA-1`
* Symmetric: `AES-CBC`, `AES-ECB`
* Signature: RSA with `PKCS#1 v1.5` padding
* Key Exchange: DHE with weak/common primes
## Deprecated SSL/Crypto APIs - FORBIDDEN
NEVER use these deprecated functions. Use the replacement APIs listed below:
### Symmetric Encryption (AES)
- Deprecated: `AES_encrypt()`, `AES_decrypt()`
- Replacement: Use EVP high-level APIs:
```c
EVP_EncryptInit_ex()
EVP_EncryptUpdate()
EVP_EncryptFinal_ex()
EVP_DecryptInit_ex()
EVP_DecryptUpdate()
EVP_DecryptFinal_ex()
```
### RSA Operations
- Deprecated: `RSA_new()`, `RSA_up_ref()`, `RSA_free()`, `RSA_set0_crt_params()`, `RSA_get0_n()`
- Replacement: Use EVP key management APIs:
```c
EVP_PKEY_new()
EVP_PKEY_up_ref()
EVP_PKEY_free()
```
### Hash Functions
- Deprecated: `SHA1_Init()`, `SHA1_Update()`, `SHA1_Final()`
- Replacement: Use EVP digest APIs:
```c
EVP_DigestInit_ex()
EVP_DigestUpdate()
EVP_DigestFinal_ex()
EVP_Q_digest() // For simple one-shot hashing
```
### MAC Operations
- Deprecated: `CMAC_Init()`, `HMAC()` (especially with SHA1)
- Replacement: Use EVP MAC APIs:
```c
EVP_Q_MAC() // For simple MAC operations
```
### Key Wrapping
- Deprecated: `AES_wrap_key()`, `AES_unwrap_key()`
- Replacement: Use EVP key wrapping APIs or implement using EVP encryption
### Other Deprecated Functions
- Deprecated: `DSA_sign()`, `DH_check()`
- Replacement: Use corresponding EVP APIs for DSA and DH operations
## Banned Insecure Algorithms - STRICTLY FORBIDDEN
These algorithms MUST NOT be used in any form:
### Hash Algorithms (Banned)
- MD2, MD4, MD5, SHA-0
- Reason: Cryptographically broken, vulnerable to collision attacks
- Use Instead: SHA-256, SHA-384, SHA-512
### Symmetric Ciphers (Banned)
- RC2, RC4, Blowfish, DES, 3DES
- Reason: Weak key sizes, known vulnerabilities
- Use Instead: AES-128, AES-256, ChaCha20
### Key Exchange (Banned)
- Static RSA key exchange
- Anonymous Diffie-Hellman
- Reason: No forward secrecy, vulnerable to man-in-the-middle attacks
- Use Instead: ECDHE, DHE with proper validation
## Broccoli Project Specific Requirements
- HMAC() with SHA1: Deprecated per Broccoli project requirements
- Replacement: Use HMAC with SHA-256 or stronger:
```c
// Instead of HMAC() with SHA1
EVP_Q_MAC(NULL, "HMAC", NULL, "SHA256", NULL, key, key_len, data, data_len, out, out_size, &out_len);
```
## Secure Crypto Implementation Pattern
```c
// Example: Secure AES encryption
EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
if (!ctx) handle_error();
if (EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, key, iv) != 1)
handle_error();
int len, ciphertext_len;
if (EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len) != 1)
handle_error();
ciphertext_len = len;
if (EVP_EncryptFinal_ex(ctx, ciphertext + len, &len) != 1)
handle_error();
ciphertext_len += len;
EVP_CIPHER_CTX_free(ctx);
```
## Code Review Checklist
- [ ] No deprecated SSL/crypto APIs used
- [ ] No banned algorithms (MD5, DES, RC4, etc.)
- [ ] HMAC uses SHA-256 or stronger (not SHA1)
- [ ] All crypto operations use EVP high-level APIs
- [ ] Proper error handling for all crypto operations
- [ ] Key material properly zeroed after use

121
skills/software-security/rules/codeguard-1-digital-certificates.md Normal file
View File

@@ -0,0 +1,121 @@
---
description: Certificate Best Practices
alwaysApply: true
---
rule_id: codeguard-1-digital-certificates
When you encounter data that appears to be an X.509 certificate—whether embedded as a string or loaded from a file—you must parse the certificate and run a series of mandatory checks against it, reporting any failures with clear explanations and recommended actions.
### 1. How to Identify Certificate Data
Actively scan for certificate data using the following heuristics:
- PEM-Encoded Strings: Identify multi-line string literals or constants that begin with `-----BEGIN CERTIFICATE-----` and end with `-----END CERTIFICATE-----`.
- File Operations: Pay close attention to file read operations on files with common certificate extensions, such as `.pem`, `.crt`, `.cer`, and `.der`.
- Library Function Calls: Recognize the usage of functions from cryptographic libraries used to load or parse certificates (e.g., OpenSSL's `PEM_read_X509`, Python's `cryptography.x509.load_pem_x509_certificate`, Java's `CertificateFactory`).
### 2. Mandatory Sanity Checks
Once certificate data is identified, you must perform the following validation steps and report the results.
#### Check 1: Expiration Status
- Condition: The certificate's `notAfter` (expiration) date is before June 23, 2025.
- Severity: CRITICAL VULNERABILITY
- Report Message: `This certificate expired on [YYYY-MM-DD]. It is no longer valid and will be rejected by clients, causing connection failures. It must be renewed and replaced immediately.`
- Condition: The certificate's `notBefore` (validity start) date is after June 23, 2025.
- Severity: Warning
- Report Message: `This certificate is not yet valid. Its validity period begins on [YYYY-MM-DD].`
#### Check 2: Public Key Strength
- Condition: The public key algorithm or size is weak.
- Weak Keys: RSA keys with a modulus smaller than 2048 bits. Elliptic Curve (EC) keys using curves with less than a 256-bit prime modulus (e.g., `secp192r1`, `P-192`, `P-224`).
- Severity: High-Priority Warning
- Report Message: `The certificate's public key is cryptographically weak ([Algorithm], [Key Size]). Keys of this strength are vulnerable to factorization or discrete logarithm attacks. The certificate should be re-issued using at least an RSA 2048-bit key or an ECDSA key on a P-256 (or higher) curve.`
#### Check 3: Signature Algorithm
- Condition: The algorithm used to sign the certificate is insecure.
- Insecure Algorithms: Any signature algorithm using MD5 or SHA-1 (e.g., `md5WithRSAEncryption`, `sha1WithRSAEncryption`).
- Severity: High-Priority Warning
- Report Message: `The certificate is signed with the insecure algorithm '[Algorithm]'. This makes it vulnerable to collision attacks, potentially allowing for certificate forgery. It must be re-issued using a signature based on the SHA-2 family (e.g., sha256WithRSAEncryption).`
#### Check 4: Issuer Type (Self-Signed Check)
- Condition: The certificate's `Issuer` and `Subject` fields are identical.
- Severity: Informational
- Report Message: `This is a self-signed certificate. Ensure this is intentional and only used for development, testing, or internal services where trust is explicitly configured. Self-signed certificates should never be used for public-facing production systems as they will not be trusted by browsers or standard clients.`
### 3. Actionable Examples
Your feedback should be direct and easy to understand.
Example 1: Flagging an Expired, In-line Certificate
- Code Snippet:
```
# Certificate for connecting to legacy_service
LEGACY_CERT = """
-----BEGIN CERTIFICATE-----
MIIC... (data for a certificate that expired on 2024-12-01) ...
-----END CERTIFICATE-----
"""
```
- Your Analysis and Report:
> CRITICAL VULNERABILITY: The certificate stored in the `LEGACY_CERT` variable is invalid.
>
> - Reason: It expired on 2024-12-01.
>
> - Impact: Any TLS connection attempting to use this certificate will fail.
>
> - Action: This certificate must be renewed and the variable updated with the new PEM data immediately.
>
Example 2: Flagging a Weak Key in a Loaded Certificate
- Code Snippet:
```
// Load the server certificate from disk
cert, err := tls.LoadX509KeyPair("server.crt", "server.key")
// Assume server.crt contains a 1024-bit RSA key.
```
- Your Analysis and Report:
> High-Priority Warning: The certificate being loaded from `server.crt` is using a weak public key.
>
> - Reason: It uses an RSA key with a 1024-bit modulus.
>
> - Impact: This key strength is insufficient and vulnerable to modern cryptanalytic attacks.
>
> - Action: A new certificate and key must be generated with at least a 2048-bit RSA key or a modern elliptic curve.
You must always explain how this rule was applied and why it was applied.

43
skills/software-security/rules/codeguard-1-hardcoded-credentials.md Normal file
View File

@@ -0,0 +1,43 @@
---
description: No Hardcoded Credentials
alwaysApply: true
---
rule_id: codeguard-1-hardcoded-credentials
# No Hardcoded Credentials
NEVER store secrets, passwords, API keys, tokens or any other credentials directly in source code.
Treat your codebase as public and untrusted. Any credential that appears in source code is compromised and must be handled through secure alternatives.
#### NEVER hardcode these types of values:
Passwords and Authentication:
- Database passwords, user passwords, admin passwords
- API keys, secret keys, access tokens, refresh tokens
- Private keys, certificates, signing keys
- Connection strings containing credentials
- OAuth client secrets, webhook secrets
- Any other credentials that could be used to access external services
#### Recognition Patterns - Learn to Spot These Formats
Common Secret Formats You Must NEVER Hardcode:
- AWS Keys: Start with `AKIA`, `AGPA`, `AIDA`, `AROA`, `AIPA`, `ANPA`, `ANVA`, `ASIA`
- Stripe Keys: Start with `sk_live_`, `pk_live_`, `sk_test_`, `pk_test_`
- Google API: Start with `AIza` followed by 35 characters
- GitHub Tokens: Start with `ghp_`, `gho_`, `ghu_`, `ghs_`, `ghr_`
- JWT Tokens: Three base64 sections separated by dots, starts with `eyJ`
- Private Key Blocks: Any text between `-----BEGIN` and `-----END PRIVATE KEY-----`
- Connection Strings: URLs with credentials like `mongodb://user:pass@host`
Warning Signs in Your Code:
- Variable names containing: `password`, `secret`, `key`, `token`, `auth`
- Long random-looking strings that are not clear what they are
- Base64 encoded strings near authentication code
- Any string that grants access to external services
You must always explain how this rule was applied and why it was applied.