D3 · Vulnerabilities and patching
This procedure defines how Bolívar Connect’s vulnerabilities are detected, classified, fixed and verified, and how security patches are applied. It covers our own code, its dependencies, the servers’ operating system, the database and the infrastructure configuration.
1. Detection sources
Section titled “1. Detection sources”| Source | Scope | When |
|---|---|---|
| Automated security tests | Tenant isolation, duplicates, signatures, scopes, idempotency | On every change |
Dependency review (npm audit) |
Production dependencies | At least once a month and before every upgrade |
| Operating system and database security advisories | Amazon Linux, PostgreSQL | When published |
| Internal code and design audit | API, data model, configuration | Upon major changes and at least once a year |
| Stress tests with integrity checks | Payment instructions, concurrency, reconciliation | Upon changes to the payment engine |
| AWS configuration review | Security groups, IAM, encryption | Upon infrastructure changes |
| External reports | Clients, third parties or researchers | When received |
2. Classification
Section titled “2. Classification”Each finding is classified by its technical severity (CVSS where available) and adjusted for its real exposure: whether the affected component is reachable from the API and which data it compromises.
| Severity | Example | Maximum remediation time |
|---|---|---|
| Critical | Remote code execution, cross-tenant access, exposure of secrets | 7 days |
| High | Privilege escalation, reachable denial of service | 30 days |
| Medium | Leak of internal information without personal data | 90 days |
| Low | Hardening or good practices | Next scheduled review |
A critical vulnerability that has been exploited or involves data exposure is also treated as an incident (D4).
3. Handling
Section titled “3. Handling”- Recording: each finding is recorded with its source, severity, component, owner and deadline.
- Containment: if it cannot be fixed immediately, a mitigation is applied, such as disabling the route, restricting by IP or rotating credentials.
- Fix: the fix includes a regression test that prevents the bug from coming back.
- Verification: the change passes the full test suite before being deployed.
- Closure: the closing date and the evidence are recorded.
If the deadline cannot be met, the exception is approved by the Security Officer, with a documented mitigation and a new date.
4. Patch management
Section titled “4. Patch management”- Operating system and database: security patches are applied within the deadlines in section 2. The rest are applied in a monthly window.
- Application dependencies: security updates are prioritized according to section 2. A major upgrade is validated in the evaluation environment before going to production.
- Deployment procedure: before a relevant change, a database snapshot is taken. The change is deployed outside peak traffic hours and the service’s health is checked afterwards.
5. Penetration testing
Section titled “5. Penetration testing”Security testing is performed at least once a year and before every major change to the exposed surface. It follows the OWASP API Security Top 10 categories and runs on an isolated environment with synthetic data. Its findings follow this same procedure. Partners who request it can run their own tests on that environment, under agreed rules.
6. Indicators
Section titled “6. Indicators”Every quarter the Security Officer reviews open findings by severity, those past their deadline and the mean time to remediation.