secure-coding-rules 2.0.0

package/src/templates/core/injection.md

@@ -0,0 +1,125 @@
+# Injection Security Rules
+
+> OWASP Top 10 2025 - A05: Injection
+
+## Rules
+
+### 1. Use Parameterized Queries for All Database Operations
+- **DO**: Use parameterized queries, prepared statements, or ORM query builders for all SQL and NoSQL operations.
+- **DON'T**: Concatenate or interpolate user input into query strings.
+- **WHY**: SQL/NoSQL injection allows attackers to read, modify, or delete entire databases and potentially execute system commands.
+
+### 2. Sanitize and Escape All Output
+- **DO**: Context-encode output before rendering in HTML, JavaScript, CSS, or URL contexts. Use framework auto-escaping.
+- **DON'T**: Insert raw user input into HTML templates or DOM elements using `innerHTML` or `dangerouslySetInnerHTML`.
+- **WHY**: Cross-Site Scripting (XSS) enables session hijacking, credential theft, and defacement.
+
+### 3. Validate and Sanitize User Input
+- **DO**: Validate input against strict schemas (type, length, format, allowed characters). Use allowlists over denylists.
+- **DON'T**: Accept any input and try to filter out known-bad patterns.
+- **WHY**: Denylist-based filtering is always incomplete. Allowlisting ensures only expected input is processed.
+
+### 4. Prevent Command Injection
+- **DO**: Avoid shell commands. If necessary, use `execFile` with an argument array instead of `exec` with string interpolation.
+- **DON'T**: Pass user input to `child_process.exec()`, `eval()`, `Function()`, or template literals in shell commands.
+- **WHY**: Command injection gives attackers full control over the server operating system.
+
+### 5. Guard Against Template Injection
+- **DO**: Use logic-less templates or sandbox template rendering. Never pass user input as template source.
+- **DON'T**: Allow users to control template strings that are compiled or rendered server-side.
+- **WHY**: Server-Side Template Injection (SSTI) can lead to Remote Code Execution (RCE).
+
+### 6. Prevent Path Traversal
+- **DO**: Resolve file paths and verify they fall within the intended directory using `path.resolve()` and prefix checking.
+- **DON'T**: Use user input directly in file system operations without path validation.
+- **WHY**: Path traversal allows reading arbitrary files like `/etc/passwd` or application secrets.
+
+### 7. Sanitize Regular Expressions
+- **DO**: Escape user input used in regular expressions. Set timeouts or use RE2 for untrusted patterns.
+- **DON'T**: Pass user input directly to `new RegExp()` without escaping.
+- **WHY**: ReDoS (Regular Expression Denial of Service) can hang the event loop with crafted input.
+
+## Code Examples
+
+### Bad Practice
+```javascript
+// SQL Injection
+const query = `SELECT * FROM users WHERE id = '${req.params.id}'`;
+await db.query(query);
+
+// NoSQL Injection
+const user = await User.findOne({ username: req.body.username, password: req.body.password });
+
+// Command Injection
+const { exec } = require("child_process");
+exec(`convert ${req.query.filename} output.png`);
+
+// Path Traversal
+const filePath = `./uploads/${req.params.filename}`;
+res.sendFile(filePath);
+
+// XSS via innerHTML
+element.innerHTML = userInput;
+
+// eval with user input
+const result = eval(req.body.expression);
+```
+
+### Good Practice
+```javascript
+import { execFile } from "node:child_process";
+import path from "node:path";
+
+// Parameterized SQL query
+const [rows] = await db.execute(
+  "SELECT * FROM users WHERE id = ?",
+  [req.params.id]
+);
+
+// Safe NoSQL query - validate types explicitly
+const username = String(req.body.username);
+const user = await User.findOne({ username });
+const isValid = await verifyPassword(req.body.password, user.passwordHash);
+
+// Safe command execution with execFile
+execFile("convert", [validatedFilename, "output.png"], (error, stdout) => {
+  if (error) handleError(error);
+});
+
+// Path traversal prevention
+function getSafeFilePath(userInput, baseDir) {
+  const resolved = path.resolve(baseDir, userInput);
+  if (!resolved.startsWith(path.resolve(baseDir) + path.sep)) {
+    throw new Error("Path traversal detected");
+  }
+  return resolved;
+}
+
+// Safe DOM manipulation
+element.textContent = userInput; // Auto-escaped, no HTML parsing
+
+// Input validation with schema
+import { z } from "zod";
+const UserInput = z.object({
+  email: z.string().email().max(254),
+  name: z.string().min(1).max(100).regex(/^[a-zA-Z\s'-]+$/),
+  age: z.number().int().min(0).max(150),
+});
+const validated = UserInput.parse(req.body);
+
+// Safe regex from user input
+function escapeRegex(str) {
+  return str.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+}
+const safePattern = new RegExp(escapeRegex(userInput), "i");
+```
+
+## Quick Checklist
+- [ ] All database queries use parameterized statements or ORM query builders
+- [ ] User input is never concatenated into SQL, NoSQL, LDAP, or OS commands
+- [ ] Output is context-encoded for the rendering context (HTML, JS, URL, CSS)
+- [ ] `eval()`, `Function()`, and `setTimeout(string)` are never used with user input
+- [ ] File paths from user input are resolved and validated against a base directory
+- [ ] Shell commands use `execFile` with argument arrays, not `exec` with string interpolation
+- [ ] Input is validated with strict schemas (type, length, format, allowlist)
+- [ ] Regular expressions from user input are escaped or use safe regex engines

package/src/templates/core/logging-alerting.md

@@ -0,0 +1,156 @@
+# Security Logging and Alerting Rules
+
+> OWASP Top 10 2025 - A09: Security Logging and Alerting Failures
+
+## Rules
+
+### 1. Log All Security-Relevant Events
+- **DO**: Log authentication attempts (success and failure), access control failures, input validation failures, and administrative actions.
+- **DON'T**: Rely on generic application logs to detect security incidents.
+- **WHY**: Without security event logging, breaches go undetected. Mean time to detect a breach averages 200+ days without proper logging.
+
+### 2. Never Log Sensitive Data
+- **DO**: Sanitize logs to exclude passwords, tokens, credit card numbers, PII, and session IDs. Use structured logging with redaction.
+- **DON'T**: Log request bodies, full headers, or raw user input without sanitization.
+- **WHY**: Logs are often stored with weaker access controls than primary data stores. Leaked logs expose credentials and PII.
+
+### 3. Use Structured, Consistent Log Formats
+- **DO**: Use JSON-structured logging with consistent fields (timestamp, level, event type, user ID, IP, request ID).
+- **DON'T**: Use unstructured `console.log()` for security events or mix log formats.
+- **WHY**: Structured logs enable automated parsing, correlation, and alerting by SIEM tools.
+
+### 4. Implement Tamper-Evident Logging
+- **DO**: Send logs to a centralized, append-only logging service. Implement log integrity checks.
+- **DON'T**: Store security logs only on the application server where an attacker could modify them.
+- **WHY**: Attackers routinely delete or modify local logs to cover their tracks.
+
+### 5. Set Up Real-Time Alerting for Critical Events
+- **DO**: Configure alerts for brute-force attempts, privilege escalation, unusual data access patterns, and authentication anomalies.
+- **DON'T**: Only review logs manually or after an incident is reported by users.
+- **WHY**: Real-time alerting reduces breach detection time from months to minutes, limiting damage.
+
+### 6. Protect Log Injection
+- **DO**: Sanitize log inputs to prevent log injection (newlines, control characters). Use parameterized logging.
+- **DON'T**: Directly interpolate user input into log messages.
+- **WHY**: Log injection can forge log entries, corrupt log analysis, or exploit log viewer vulnerabilities.
+
+### 7. Ensure Adequate Log Retention
+- **DO**: Retain security logs for at least 90 days (hot) and 1 year (cold) per compliance requirements.
+- **DON'T**: Delete logs immediately after processing or keep them indefinitely without retention policies.
+- **WHY**: Incident investigation often requires historical log analysis. Retention policies balance security with storage costs and privacy regulations.
+
+## Code Examples
+
+### Bad Practice
+```javascript
+// Logging sensitive data
+console.log(`User login: ${email}, password: ${password}`);
+console.log(`Payment processed: card=${cardNumber}, amount=${amount}`);
+
+// Log injection vulnerability
+const username = req.body.username; // Could contain "\nAdmin login successful"
+console.log(`Login attempt for user: ${username}`);
+
+// No security event logging
+app.post("/api/login", async (req, res) => {
+  const user = await authenticate(req.body);
+  if (user) res.json({ token: createToken(user) });
+  else res.status(401).json({ error: "Invalid" });
+  // No logging of success or failure
+});
+```
+
+### Good Practice
+```javascript
+import pino from "pino";
+
+// Structured logger with redaction
+const logger = pino({
+  level: "info",
+  redact: {
+    paths: ["password", "token", "authorization", "cookie", "*.password", "*.token"],
+    censor: "[REDACTED]",
+  },
+  serializers: {
+    req: pino.stdSerializers.req,
+    err: pino.stdSerializers.err,
+  },
+});
+
+// Security event logger
+function logSecurityEvent(event) {
+  logger.info({
+    type: "security",
+    event: event.action,
+    userId: event.userId ?? "anonymous",
+    ip: event.ip,
+    userAgent: event.userAgent,
+    resource: event.resource,
+    outcome: event.outcome,
+    timestamp: new Date().toISOString(),
+    requestId: event.requestId,
+  });
+}
+
+// Login with comprehensive security logging
+app.post("/api/login", loginLimiter, async (req, res) => {
+  const { email, password } = req.body;
+  const requestId = crypto.randomUUID();
+  const user = await db.findUser(email);
+  const isValid = user ? await verifyPassword(password, user.passwordHash) : false;
+
+  logSecurityEvent({
+    action: isValid ? "login_success" : "login_failure",
+    userId: user?.id,
+    ip: req.ip,
+    userAgent: req.get("user-agent"),
+    resource: "/api/login",
+    outcome: isValid ? "success" : "failure",
+    requestId,
+  });
+
+  if (!isValid) {
+    return res.status(401).json({ error: "Invalid credentials", requestId });
+  }
+
+  setSessionCookie(res, user);
+  res.json({ success: true });
+});
+
+// Safe log message - prevent log injection
+function sanitizeForLog(input) {
+  if (typeof input !== "string") return String(input);
+  return input.replace(/[\n\r\t]/g, "").substring(0, 500);
+}
+
+// Access control failure logging middleware
+function logAccessDenied(req, res, next) {
+  const originalJson = res.json.bind(res);
+  res.json = (body) => {
+    if (res.statusCode === 403) {
+      logSecurityEvent({
+        action: "access_denied",
+        userId: req.user?.id,
+        ip: req.ip,
+        userAgent: req.get("user-agent"),
+        resource: `${req.method} ${req.originalUrl}`,
+        outcome: "denied",
+        requestId: req.id,
+      });
+    }
+    return originalJson(body);
+  };
+  next();
+}
+```
+
+## Quick Checklist
+- [ ] Authentication successes and failures are logged
+- [ ] Access control violations are logged
+- [ ] No passwords, tokens, or PII in log output
+- [ ] Structured JSON logging format with consistent fields
+- [ ] Logs sent to centralized, tamper-resistant storage
+- [ ] Real-time alerts configured for critical security events
+- [ ] Log inputs sanitized to prevent log injection
+- [ ] Log retention policy defined and enforced (90 days+)
+- [ ] Each log entry includes timestamp, user ID, IP, and request ID

package/src/templates/core/secure-design.md

@@ -0,0 +1,117 @@
+# Insecure Design Security Rules
+
+> OWASP Top 10 2025 - A06: Insecure Design
+
+## Rules
+
+### 1. Apply Threat Modeling During Design
+- **DO**: Identify trust boundaries, data flows, and threat actors before writing code. Use STRIDE or similar frameworks.
+- **DON'T**: Bolt security onto the application after implementation.
+- **WHY**: Security flaws rooted in design cannot be fixed by better implementation alone. Architecture-level vulnerabilities require redesign.
+
+### 2. Enforce Business Logic Limits
+- **DO**: Implement server-side limits for business operations (e.g., max transaction amount, order quantity, API calls per user).
+- **DON'T**: Rely on the UI to enforce business rules like purchase limits or booking constraints.
+- **WHY**: Business logic abuse (e.g., buying items at negative prices, mass-redeeming coupons) bypasses client-side validation easily.
+
+### 3. Implement Defense in Depth
+- **DO**: Layer multiple security controls so that failure of one does not compromise the system. Combine input validation, access control, encryption, and monitoring.
+- **DON'T**: Depend on a single security mechanism to protect critical assets.
+- **WHY**: No single control is perfect. Layered defenses ensure that an attacker must defeat multiple barriers.
+
+### 4. Follow the Principle of Least Privilege
+- **DO**: Grant minimum necessary permissions to users, services, and processes. Use separate service accounts with scoped credentials.
+- **DON'T**: Run services as root, use admin-level database credentials for application queries, or grant blanket permissions.
+- **WHY**: Over-privileged components amplify the impact of any breach, turning a small vulnerability into full system compromise.
+
+### 5. Design for Abuse Cases
+- **DO**: For every feature, ask "how could this be abused?" and implement safeguards (rate limiting, CAPTCHA, fraud detection).
+- **DON'T**: Only consider the happy path in feature design. Assume all input can be malicious.
+- **WHY**: Attackers use features in unintended ways. Referral systems get exploited, file uploads deliver malware, search becomes a data exfiltration tool.
+
+### 6. Separate Sensitive Operations
+- **DO**: Require re-authentication or multi-factor confirmation for critical operations (password change, fund transfer, account deletion).
+- **DON'T**: Allow destructive or sensitive operations with a single click or without additional verification.
+- **WHY**: Session hijacking or CSRF can trigger sensitive operations. Step-up authentication adds a security boundary.
+
+## Code Examples
+
+### Bad Practice
+```javascript
+// No business logic validation on the server
+app.post("/api/transfer", authenticate, async (req, res) => {
+  const { amount, toAccount } = req.body;
+  // Trusting client-sent amount without validation
+  await transferFunds(req.user.id, toAccount, amount);
+  res.json({ success: true });
+});
+
+// Feature without abuse consideration
+app.post("/api/referral", authenticate, async (req, res) => {
+  // No limit on referral bonuses - can be exploited with fake accounts
+  await addReferralBonus(req.user.id, req.body.referralCode);
+  res.json({ success: true });
+});
+```
+
+### Good Practice
+```javascript
+import { z } from "zod";
+import { rateLimit } from "express-rate-limit";
+
+// Business logic with server-side validation and limits
+const TransferSchema = z.object({
+  amount: z.number().positive().max(10000), // Business limit
+  toAccount: z.string().regex(/^\d{10,12}$/),
+});
+
+app.post("/api/transfer", authenticate, async (req, res) => {
+  const { amount, toAccount } = TransferSchema.parse(req.body);
+
+  // Check daily transfer limit
+  const dailyTotal = await getDailyTransferTotal(req.user.id);
+  if (dailyTotal + amount > req.user.dailyLimit) {
+    return res.status(400).json({ error: "Daily transfer limit exceeded" });
+  }
+
+  // Require step-up authentication for large transfers
+  if (amount > 1000) {
+    const mfaVerified = await verifyMFA(req.user.id, req.body.mfaToken);
+    if (!mfaVerified) {
+      return res.status(403).json({ error: "MFA required for large transfers" });
+    }
+  }
+
+  await transferFunds(req.user.id, toAccount, amount);
+  await logAuditEvent("transfer", { userId: req.user.id, amount, toAccount });
+  res.json({ success: true });
+});
+
+// Referral system with abuse prevention
+const referralLimiter = rateLimit({ windowMs: 24 * 60 * 60 * 1000, max: 5 });
+
+app.post("/api/referral", authenticate, referralLimiter, async (req, res) => {
+  const referrer = await getUserByReferralCode(req.body.referralCode);
+
+  // Abuse checks
+  if (referrer.id === req.user.id) {
+    return res.status(400).json({ error: "Cannot refer yourself" });
+  }
+  const existingReferral = await getReferral(req.user.id);
+  if (existingReferral) {
+    return res.status(400).json({ error: "Already used a referral" });
+  }
+
+  await addReferralBonus(referrer.id, req.user.id);
+  res.json({ success: true });
+});
+```
+
+## Quick Checklist
+- [ ] Threat modeling performed for critical features
+- [ ] Business logic limits enforced server-side (not just client-side)
+- [ ] Multiple layers of security controls (defense in depth)
+- [ ] Services run with minimum required privileges
+- [ ] Abuse cases identified and mitigated for each feature
+- [ ] Sensitive operations require step-up authentication or MFA
+- [ ] Data flows and trust boundaries documented

package/src/templates/core/security-config.md

@@ -0,0 +1,118 @@
+# Security Configuration Rules
+
+> OWASP Top 10 2025 - A02: Security Misconfiguration
+
+## Rules
+
+### 1. Disable Verbose Error Messages in Production
+- **DO**: Return generic error responses to clients. Log detailed errors server-side only.
+- **DON'T**: Expose stack traces, database errors, or internal paths in API responses.
+- **WHY**: Verbose errors leak implementation details that attackers use for targeted exploitation.
+
+### 2. Remove Default Credentials and Configurations
+- **DO**: Change all default passwords, API keys, and configuration values before deployment.
+- **DON'T**: Ship applications with default admin accounts, sample configurations, or debug settings enabled.
+- **WHY**: Default credentials are the first thing attackers try and are widely documented.
+
+### 3. Set Secure HTTP Headers
+- **DO**: Configure security headers: `Strict-Transport-Security`, `X-Content-Type-Options`, `X-Frame-Options`, `Content-Security-Policy`, and `Permissions-Policy`.
+- **DON'T**: Rely on framework defaults without verifying which security headers are actually set.
+- **WHY**: Security headers provide defense-in-depth against XSS, clickjacking, MIME sniffing, and protocol downgrade attacks.
+
+### 4. Disable Unnecessary Features and Services
+- **DO**: Remove or disable unused routes, middleware, debug endpoints, and server features (e.g., directory listing, `X-Powered-By`).
+- **DON'T**: Leave development tools, test endpoints, or administrative panels accessible in production.
+- **WHY**: Every unnecessary feature expands the attack surface.
+
+### 5. Enforce HTTPS Everywhere
+- **DO**: Redirect all HTTP traffic to HTTPS. Use HSTS with a long `max-age` and `includeSubDomains`.
+- **DON'T**: Allow mixed content or serve any resources over plain HTTP.
+- **WHY**: Unencrypted traffic is vulnerable to interception, modification, and man-in-the-middle attacks.
+
+### 6. Configure CORS Restrictively
+- **DO**: Set `Access-Control-Allow-Origin` to specific trusted domains. Validate the `Origin` header server-side.
+- **DON'T**: Use `Access-Control-Allow-Origin: *` with credentials or reflect any origin without validation.
+- **WHY**: Overly permissive CORS allows malicious sites to make authenticated requests on behalf of users.
+
+### 7. Harden Environment Configuration
+- **DO**: Use environment variables or secret managers for sensitive configuration. Validate all config values at startup.
+- **DON'T**: Commit secrets to version control or store them in plain-text config files.
+- **WHY**: Leaked secrets in repositories are a leading cause of breaches.
+
+## Code Examples
+
+### Bad Practice
+```javascript
+// Leaking internal details in error responses
+app.use((err, req, res, next) => {
+  res.status(500).json({
+    error: err.message,
+    stack: err.stack,          // Exposes internals
+    query: err.sql,            // Exposes database queries
+  });
+});
+
+// Permissive CORS
+app.use(cors({ origin: "*", credentials: true })); // Dangerous combination
+
+// Hardcoded secrets
+const JWT_SECRET = "super-secret-key-123";
+const DB_PASSWORD = "admin123";
+```
+
+### Good Practice
+```javascript
+import helmet from "helmet";
+import cors from "cors";
+
+// Security headers with helmet
+app.use(helmet());
+app.use(helmet.hsts({ maxAge: 31536000, includeSubDomains: true, preload: true }));
+
+// Remove powered-by header
+app.disable("x-powered-by");
+
+// Restrictive CORS
+const ALLOWED_ORIGINS = process.env.ALLOWED_ORIGINS?.split(",") ?? [];
+app.use(cors({
+  origin(origin, callback) {
+    if (!origin || ALLOWED_ORIGINS.includes(origin)) {
+      callback(null, true);
+    } else {
+      callback(new Error("Not allowed by CORS"));
+    }
+  },
+  credentials: true,
+  methods: ["GET", "POST", "PUT", "DELETE"],
+  maxAge: 86400,
+}));
+
+// Safe error handler for production
+app.use((err, req, res, next) => {
+  const errorId = crypto.randomUUID();
+  console.error({ errorId, message: err.message, stack: err.stack });
+  res.status(err.status ?? 500).json({
+    error: "An internal error occurred",
+    errorId, // For support reference only
+  });
+});
+
+// Validate required config at startup
+const requiredEnvVars = ["JWT_SECRET", "DATABASE_URL", "ALLOWED_ORIGINS"];
+for (const envVar of requiredEnvVars) {
+  if (!process.env[envVar]) {
+    throw new Error(`Missing required environment variable: ${envVar}`);
+  }
+}
+```
+
+## Quick Checklist
+- [ ] No stack traces or internal details in production error responses
+- [ ] All default credentials removed or changed
+- [ ] Security headers configured (HSTS, CSP, X-Content-Type-Options, etc.)
+- [ ] `X-Powered-By` and other fingerprinting headers disabled
+- [ ] HTTPS enforced with HSTS
+- [ ] CORS configured with specific allowed origins
+- [ ] No secrets in source code or version control
+- [ ] Unused routes, debug endpoints, and dev tools disabled in production
+- [ ] Environment configuration validated at application startup

package/src/templates/core/supply-chain.md

@@ -0,0 +1,127 @@
+# Software Supply Chain Security Rules
+
+> OWASP Top 10 2025 - A03: Software Supply Chain Failures (NEW)
+
+## Rules
+
+### 1. Audit Dependencies Regularly
+- **DO**: Run `npm audit` in CI/CD pipelines. Use tools like Socket.dev or Snyk to detect malicious or vulnerable packages.
+- **DON'T**: Ignore audit warnings or suppress them without reviewing each finding.
+- **WHY**: Known vulnerabilities in dependencies are a top attack vector. Automated auditing catches issues before deployment.
+
+### 2. Pin Dependency Versions
+- **DO**: Use exact versions or lockfiles (`package-lock.json`, `pnpm-lock.yaml`) and commit them to version control.
+- **DON'T**: Use loose version ranges (e.g., `^` or `*`) for production dependencies without lockfile enforcement.
+- **WHY**: Unpinned versions allow silent upgrades that may introduce vulnerabilities or malicious code.
+
+### 3. Verify Lockfile Integrity
+- **DO**: Enable lockfile-only installs in CI (`npm ci` or `--frozen-lockfile`). Detect and reject unexpected lockfile changes.
+- **DON'T**: Run `npm install` in CI, which can modify the lockfile and pull in unreviewed versions.
+- **WHY**: Lockfile manipulation is a supply chain attack vector. Strict installs ensure reproducible, verified builds.
+
+### 4. Use Subresource Integrity (SRI)
+- **DO**: Add `integrity` attributes to all external `<script>` and `<link>` tags loading from CDNs.
+- **DON'T**: Load external scripts without integrity verification.
+- **WHY**: SRI ensures the browser rejects tampered CDN assets, preventing supply chain attacks via compromised CDNs.
+
+### 5. Minimize Dependency Surface
+- **DO**: Evaluate each dependency for necessity, maintenance status, and security posture before adding it.
+- **DON'T**: Add packages for trivial functionality that can be implemented in a few lines of code.
+- **WHY**: Each dependency is a trust relationship. Fewer dependencies mean a smaller attack surface and less risk of transitive vulnerabilities.
+
+### 6. Monitor for Typosquatting and Malicious Packages
+- **DO**: Double-check package names before installing. Use scoped packages (`@org/package`) where possible.
+- **DON'T**: Install packages without verifying the publisher, download count, and repository link.
+- **WHY**: Typosquatting attacks publish packages with similar names to popular libraries, injecting malicious code.
+
+### 7. Enforce Build Reproducibility
+- **DO**: Use deterministic builds. Pin Node.js versions, use lockfiles, and build in controlled environments.
+- **DON'T**: Allow builds to fetch latest versions at build time or rely on mutable tags like `latest`.
+- **WHY**: Non-reproducible builds make it impossible to verify that deployed code matches reviewed source.
+
+### 8. Restrict Install Scripts
+- **DO**: Use `--ignore-scripts` flag when installing untrusted packages. Review `preinstall` and `postinstall` scripts.
+- **DON'T**: Allow arbitrary install scripts to run without review, especially from new or unvetted dependencies.
+- **WHY**: Malicious install scripts can execute arbitrary code during `npm install`, compromising the build environment.
+
+## Code Examples
+
+### Bad Practice
+```json
+// package.json with loose version ranges
+{
+  "dependencies": {
+    "lodash": "*",
+    "express": "^4",
+    "some-unknown-pkg": "latest"
+  }
+}
+```
+
+```html
+<!-- Loading CDN scripts without integrity check -->
+<script src="https://cdn.example.com/lib/v3/analytics.min.js"></script>
+```
+
+```yaml
+# CI pipeline using npm install (modifies lockfile)
+steps:
+  - run: npm install
+  - run: npm run build
+```
+
+### Good Practice
+```json
+// package.json with pinned versions
+{
+  "dependencies": {
+    "lodash": "4.17.21",
+    "express": "4.21.2"
+  },
+  "overrides": {
+    "vulnerable-transitive-dep": ">=2.0.1"
+  }
+}
+```
+
+```html
+<!-- CDN scripts with SRI -->
+<script
+  src="https://cdn.example.com/lib/v3/analytics.min.js"
+  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
+  crossorigin="anonymous"
+></script>
+```
+
+```yaml
+# CI pipeline with frozen lockfile and audit
+steps:
+  - run: npm ci --ignore-scripts   # Frozen lockfile, no scripts
+  - run: npm audit --audit-level=high
+  - run: npx lockfile-lint --path package-lock.json --type npm --allowed-hosts npm
+  - run: npm run build
+```
+
+```javascript
+// Runtime dependency verification helper
+import { createHash } from "node:crypto";
+import { readFile } from "node:fs/promises";
+
+async function verifyFileIntegrity(filePath, expectedHash) {
+  const content = await readFile(filePath);
+  const hash = createHash("sha384").update(content).digest("base64");
+  if (hash !== expectedHash) {
+    throw new Error(`Integrity check failed for ${filePath}`);
+  }
+}
+```
+
+## Quick Checklist
+- [ ] `npm audit` (or equivalent) runs in CI on every build
+- [ ] `package-lock.json` is committed and CI uses `npm ci`
+- [ ] No wildcard (`*`) or `latest` version ranges in production dependencies
+- [ ] External CDN scripts use SRI `integrity` attributes
+- [ ] New dependencies are reviewed for security posture before adoption
+- [ ] Install scripts are reviewed or disabled for untrusted packages
+- [ ] Node.js version is pinned in `.nvmrc` or `engines` field
+- [ ] Dependency update PRs are reviewed for unexpected changes