cisco-ai-skill-scanner 1.0.0__tar.gz

cisco_ai_skill_scanner-1.0.0/.cursor/rules/codeguard-0-additional-cryptography.mdc

@@ -0,0 +1,58 @@
+---
+description: Additional Cryptography guidance
+globs: **/*.c,**/*.go,**/*.h,**/*.java,**/*.js,**/*.jsx,**/*.kt,**/*.kts,**/*.m,**/*.mjs,**/*.php,**/*.py,**/*.pyi,**/*.pyx,**/*.rb,**/*.swift,**/*.ts,**/*.tsx,**/*.wsdl,**/*.xml,**/*.xsd,**/*.xslt,**/*.yaml,**/*.yml
+version: 1.0.1
+---
+
+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.

cisco_ai_skill_scanner-1.0.0/.cursor/rules/codeguard-0-framework-and-languages.mdc

@@ -0,0 +1,111 @@
+---
+description: Framework & language security guides (Django/DRF, Laravel/Symfony/Rails, .NET, Java/JAAS, Node.js, PHP config)
+globs: **/*.c,**/*.h,**/*.java,**/*.js,**/*.jsx,**/*.kt,**/*.kts,**/*.mjs,**/*.php,**/*.py,**/*.pyi,**/*.pyx,**/*.rb,**/*.ts,**/*.tsx,**/*.wsdl,**/*.xml,**/*.xsd,**/*.xslt,**/*.yaml,**/*.yml
+version: 1.0.1
+---
+
+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.

cisco_ai_skill_scanner-1.0.0/.cursor/rules/codeguard-0-iac-security.mdc

@@ -0,0 +1,79 @@
+---
+description: Infrastructure as Code Security
+globs: **/*.bash,**/*.c,**/*.d,**/*.h,**/*.js,**/*.jsx,**/*.mjs,**/*.ps1,**/*.rb,**/*.sh,**/*.yaml,**/*.yml
+version: 1.0.1
+---
+
+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.

cisco_ai_skill_scanner-1.0.0/.cursor/rules/codeguard-0-mobile-apps.mdc

@@ -0,0 +1,108 @@
+---
+description: 'Mobile app security (iOS/Android): storage, transport, code integrity, biometrics, permissions'
+globs: **/*.java,**/*.js,**/*.jsx,**/*.kt,**/*.kts,**/*.m,**/*.mjs,**/*.pl,**/*.pm,**/*.swift,**/*.wsdl,**/*.xml,**/*.xsd,**/*.xslt
+version: 1.0.1
+---
+
+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.

cisco_ai_skill_scanner-1.0.0/.cursor/rules/codeguard-0-supply-chain-security.mdc

@@ -0,0 +1,47 @@
+---
+description: Dependency & supply chain security (pinning, SBOM, provenance, integrity, private registries)
+globs: **/*.dockerfile,**/*.js,**/*.jsx,**/*.mjs,**/*.yaml,**/*.yml,Dockerfile*,docker-compose*
+version: 1.0.1
+---
+
+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.

cisco_ai_skill_scanner-1.0.0/.cursor/rules/codeguard-1-crypto-algorithms.mdc

@@ -0,0 +1,136 @@
+---
+description: Cryptographic Security Guidelines
+globs: **/*
+version: 1.0.1
+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

cisco_ai_skill_scanner-1.0.0/.cursor/rules/codeguard-1-digital-certificates.mdc

@@ -0,0 +1,123 @@
+---
+description: Certificate Best Practices
+globs: **/*
+version: 1.0.1
+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.