Security Best Practices
Dependency Auditing
Run
pnpm audit regularly — ideally on every pull request — to surface known CVEs in your dependency tree before they reach production.Secret Management
Never commit secrets to source control. Store all credentials and API keys in environment variables, and use a dedicated secrets manager in production environments.
Type Safety
Enable TypeScript strict mode across all packages. Strong typing eliminates entire classes of injection vulnerabilities and reduces the surface area for runtime surprises.
Dependency Pinning
Use exact version specifiers (no
^ or ~) in production packages. Pinned versions ensure that your dependency tree is deterministic and cannot silently introduce a compromised release.Responding to a Security Incident
1
Confirm the vulnerability
Gather the CVE number, the name and version range of the affected package, and the attack vector. Use the npm advisory database or the GitHub Advisory Database to retrieve official details.
2
Assess impact
Determine whether the vulnerability is exploitable in your specific deployment. A vulnerability in a server-side package that is only used in a CLI tool may carry far less risk than the same CVSS score applied to a public API.
3
Isolate affected services if actively exploited
If you have evidence of active exploitation — unusual request patterns, unexpected data access, or confirmed breach indicators — isolate the affected service immediately. Take it out of the load balancer rotation, revoke compromised credentials, and preserve logs before taking any destructive action.
4
Apply the fix
Choose the remediation path appropriate for the vulnerability:
- Update the dependency to a patched version.
- Patch the code if the vulnerability is in your own application logic.
- Apply a workaround (e.g., disable a vulnerable feature flag) if a patched version is not yet available.
5
Deploy the fix
Run the fix through your standard deployment pipeline. Do not deploy directly from a local machine — use CI to ensure the fix is reviewed, tested, and auditable. Follow the Deployment Runbook for the full procedure.
6
Notify affected parties
Follow your organisation’s responsible disclosure policy. Notify internal stakeholders, downstream consumers of affected packages, and — where legally required — any affected users or regulators within the required timeframe.
7
Document in a security post-mortem
Record what the vulnerability was, how it was discovered, how long it was present, what data or systems were at risk, and what changes you are making to prevent similar issues. File this in your team’s knowledge base.
Dependency Vulnerability Scanning
Integrate these commands into your local workflow and CI pipeline to catch vulnerable dependencies before they ship.Secrets Management
Follow these practices to ensure credentials never leak from your Figentra project:- Use
.envfiles locally for development secrets, and add.envto.gitignore. Never commit a.envfile — not even one containing only “placeholder” values that could mislead future contributors. - Use your platform’s secrets manager in production — AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Doppler, or equivalent. Inject secrets as environment variables at runtime rather than baking them into container images or config files.
- Validate all environment variables at startup using
@figentra/config. This ensures your application fails fast with a clear error message if a required secret is missing, rather than silently misbehaving at runtime.