# Entea vulnerability-management policy

Last updated: 18 September 2026  
Status: Interim operating policy; independent assessment pending

## Intake

Security findings may come from engineering review, automated tests, dependency advisories, customer reports, provider notices, or an independent assessment. Reports should be sent through https://entea.in/support or to connect@entea.in with the subject “Security report.”

Do not include live credentials, tokens, private keys, or unnecessary customer data in the initial report. Entea does not currently operate a public bug-bounty program and does not authorize destructive testing of production systems.

## Triage

Findings are classified by exploitability, affected data, tenant-boundary impact, required access, availability impact, and the presence of compensating controls. Confirmed cross-tenant access, credential disclosure, or remotely exploitable production compromise is treated as critical.

## Remediation targets

These are internal operating targets, not contractual guarantees:

| Severity | Target |
| --- | --- |
| Critical | Contain immediately; remediation target within 72 hours |
| High | Remediation target within 14 days |
| Moderate | Remediation target within 30 days |
| Low | Remediation target within 90 days or the next planned release |

A documented risk decision, compensating control, or dependency constraint may change a target. Exceptions require an owner and review date.

## Release checks currently in use

- lint, TypeScript verification, unit tests, and production builds in deployment CI;
- authenticated sign-in, MFA, and tenant-isolation browser tests maintained in the repository;
- generated-source policy validation and immutable build quality evidence;
- dependency lockfiles and explicit package versions;
- credential encryption and tamper-rejection tests;
- health and acceptance checks before deployment promotion.

## Known gaps

- An independent penetration test has not been completed.
- A dedicated dependency and static-analysis security scan is not currently shown in the production GitHub Actions workflow.
- Managed malware scanning remains a production-readiness requirement beyond built-in upload screening.

These gaps must remain visible until evidence shows they are closed.