Security Policy Base

Owner	Flowdence Security and Engineering
Applies to app	All Flowdence Marketplace cloud apps
Review cadence	Quarterly and after any significant security event
Status	Baseline policy

1. Secure development lifecycle

• Source control with reviewed changes.
• Release gates include lint/test/validation as defined per app.
• Production claims must be traceable to implementation.

2. Access control and least privilege

• App permissions are scoped to minimum required capability.
• Administrative operations require explicit authorization checks.
• Company systems use multi-factor authentication where supported.
• Access to source control, Marketplace administration, support systems, deployment tooling, and security-sensitive logs is reviewed periodically.

3. Secrets and credential management

• Secrets are not stored in source code.
• Runtime secrets are stored in approved secure stores.
• Secret rotation process exists and is documented per app.
• Customer-provided third-party tokens are stored only in approved secret storage and are not returned to app frontends after save.

4. Logging and monitoring

• Production logging avoids unnecessary sensitive data.
• Monitoring and alerting are defined with responder ownership.
• Logs must not include API tokens, passwords, private keys, recovery codes, or raw rendered binary payloads.

5. Vulnerability management

• Security issues are triaged and remediated by severity.
• Marketplace security requirement timelines are treated as release constraints.
• Dependency and open-source component reviews are part of the release process.
• Flowdence maintains severity-based remediation targets for critical, high, medium, and low findings.

6. Incident response

• Incident triage, escalation, and communication runbooks are maintained.
• Post-incident review and corrective actions are tracked to closure.
• Flowdence uses Atlassian Marketplace incident and vulnerability notification guidance when a Marketplace app security incident or critical vulnerability requires notification.
• Business continuity and disaster recovery plans are reviewed and tested at least annually.

7. Vendor and component review

• Direct vendors and subprocessors are reviewed before onboarding and periodically afterward.
• Open-source components are reviewed through dependency scanning, lockfile review, SBOM practices, and license/package health checks.
• Customer-configured upstream platforms are documented separately from Flowdence-controlled subprocessors.

8. Security reporting

• Contact: security@flowdence.io
• Report format: include impact, reproduction steps, and affected environments.