Security — FireFeed

Network protection

Production databases are not exposed to the public internet. They are reachable only from the application network.
Access to internal services is restricted via private networking, security groups and firewall rules.
Only the ports strictly required for the service are exposed externally.
Production, staging and development run in separated environments with separated credentials and data.
Public endpoints are protected by rate limiting and abuse controls; a Web Application Firewall layer is used in front of HTTP entry points.
Administrative access is restricted to authorized operators on hardened workstations and over secured channels.

All HTTP traffic is served over HTTPS with valid TLS certificates.
HTTP requests are redirected to HTTPS.
HSTS is enabled on production hostnames.
Internal service-to-service communication uses TLS or runs over a private network.
SP-API calls are made exclusively over HTTPS and follow Amazon's authentication and signing requirements.

Production storage volumes are encrypted at rest.
Sensitive fields (including Amazon recipient and shipping information) are encrypted at the application layer using AES-256.
Credentials, SP-API tokens and integration secrets are stored in a managed secret store, not in the application database in plain form.
Encryption keys are managed by a key-management facility, with restricted access and audited usage.
Key rotation is performed on a documented cadence and on suspected compromise.

Each operator and team member has an individual user account; shared accounts are not permitted.
Role-based access control (RBAC) enforces the principle of least privilege.
Multi-factor authentication is required for all administrative accounts and for access to systems handling Amazon Information.
Access to production systems is reviewed periodically; access is revoked on role change or termination.
All access events are logged and reviewed.

No secrets are committed to source repositories. Repositories are scanned for accidental secret exposure.
Secrets are injected at runtime from environment variables backed by a managed secret store.
Secrets and tokens are rotated on a defined schedule and on any suspected compromise.
Secrets are masked in application logs and error reports.
Password policy requires sufficient length and complexity; reuse of breached passwords is blocked where the underlying system supports it.

Centralized application and security logs, with structured events for auditability.
Audit log of access to systems handling Amazon Information.
Alerting on suspicious authentication, configuration changes, and abnormal access patterns.
Periodic review of security logs by the operations team.
Log retention is set to support investigations; retention is at least 12 months for security-relevant logs.

Automated dependency scanning on every build, with alerts on known vulnerabilities.
Static code analysis on the main branch and on pull requests.
Operating system and base image patching as part of the regular build cycle.
Critical vulnerabilities are remediated within 7 days; high-severity vulnerabilities within 30 days, in line with severity-based timelines.
Changes are validated in staging before deployment to production.
Pull requests require code review before merge.

Documented incident response procedure covering detection, containment, analysis, recovery and post-mortem.
Defined roles and responsibilities for security incidents.
For incidents involving Amazon Information, FireFeed will notify Amazon within 24 hours of confirmed detection, in line with Amazon's Data Protection Policy.
Affected sellers and data subjects are notified in line with applicable obligations.
Each incident is followed by a post-mortem and a tracked set of corrective actions.

For security questions, vulnerability reports or incident notifications involving FireFeed or Amazon Information, contact security@fire-feed.com.