39 lines
1.7 KiB
Markdown
39 lines
1.7 KiB
Markdown
# Security Policy
|
|
|
|
## Supported code
|
|
|
|
Security fixes target the current `main` release line. Historical research,
|
|
calibration and development branches are not supported release channels unless
|
|
explicitly documented otherwise.
|
|
|
|
## Reporting vulnerabilities
|
|
|
|
Report suspected security issues privately to the repository owner. Do not put
|
|
credentials, access tokens, private infrastructure, precise sensitive
|
|
locations, proprietary imagery or datasets, model artifacts, production
|
|
database contents, personal data or exploit-sensitive evidence in a public
|
|
issue.
|
|
|
|
Include the affected commit and component, minimal reproduction conditions
|
|
using synthetic or public data where possible, expected and observed
|
|
behaviour, impact, and whether the issue affects ingestion, geospatial
|
|
processing, authentication or authorization, uploads, archive or path handling,
|
|
model inference, reports and exports, deployment, data retention or secrets.
|
|
|
|
## Repository and data boundary
|
|
|
|
Geospatial inputs and derived outputs can reveal people, assets and sensitive
|
|
locations. Treat screenshots, contact sheets, coordinates, source archives,
|
|
SQLite/WAL state, model output and exports as potentially sensitive. These
|
|
belong in controlled external storage, not the source repository.
|
|
|
|
Local Codex inputs, calibration databases, runtime data, generated reports and
|
|
cross-project scratch are not release source. Never commit live `.env` files,
|
|
private keys, production backups or databases, customer or operator data,
|
|
unpublished imagery, credentials or private datasets. Public examples and tests
|
|
must use synthetic or explicitly redistributable material.
|
|
|
|
## Disclosure
|
|
|
|
Coordinate remediation and disclosure with the repository owner before publishing details that would materially increase exploitation risk.
|