iDev Soluções

Security Policy for App and Integration Development

Version: 1.0
Date: 2026-03-02
Applies to: All employees, contractors, and third parties who design, build, maintain, or operate apps, scripts, automations, and integrations for any customer.

1. Purpose

This policy defines iDev Soluções’ minimum security controls for producing and operating software that integrates with third-party platforms and customer environments. It is designed to protect confidentiality, integrity, and availability of customer data and iDev assets while keeping the policy practical for a small team.

2. Scope

This policy applies to:

• Atlassian Marketplace apps (Forge and Connect)
• Private integrations, scripts, and automations for customers
• CI/CD pipelines, repositories, and build systems used for delivery
• Systems and endpoints used to access code, secrets, and customer data

3. Security Principles

• Least privilege: request only the minimum permissions and scopes needed for functionality.
• No secrets in code or logs: credentials and tokens must never be committed, printed, or exposed in URLs.
• Encrypt in transit: all external traffic must use TLS 1.2 or higher.
• Secure by default: validate, sanitize, and authorize every request and data access.
• Rapid remediation: security vulnerabilities are triaged and fixed within defined timelines.

4. Roles and Responsibilities

Policy Owner (Security Owner)

• Owns this policy, approves exceptions, oversees incident response.

App Owner (per app or integration)

• Accountable for secure design, scope minimization, release readiness, and compliance obligations.

Developers and Implementers

• Follow secure development practices, protect secrets, and report risks or incidents immediately.

Operations and Support (when applicable)

• Monitor relevant logs, manage access reviews, and enforce release and change controls.

5. Baseline Controls for Endpoints and Accounts

5.1 Endpoint security

• Company and personal devices used for iDev work must be protected by full disk encryption.
• Devices must use supported operating systems with automatic security updates enabled.
• Anti-malware and host firewall must be enabled.
• Devices must lock automatically when unattended.

5.2 Identity and access management

• Multi-factor authentication is required for:
• GitHub
• Email accounts used for Marketplace, customer support, or security notifications
• Any cloud provider or SaaS used to store data or secrets
• Access must follow least privilege and be reviewed periodically, especially for admin roles.
• Shared accounts are not allowed.

6. Source Control and CI/CD Security (GitHub)

• GitHub is the authoritative source control platform for iDev app and integration code.
• Branch protection must be enabled for default branches:
• Pull request required for changes
• At least one reviewer required for merges
• No direct pushes to protected branches
• Changes to security-sensitive code require review by an App Owner or Security Owner.
• CI/CD secrets must be stored using GitHub secrets or an approved secret manager, never in code.

7. Dependency and Vulnerability Scanning (npm and Marketplace context)

• iDev uses npm vulnerability scanning to identify known issues in JavaScript dependencies:
• npm audit (or equivalent) must be executed in CI for Node-based projects where applicable.
• For Atlassian Marketplace apps, iDev also tracks findings and tickets coming from Atlassian Marketplace security processes where applicable.
• Vulnerability findings must be triaged, tracked, and resolved within the remediation timelines in this policy.

8. Secure Development Lifecycle (Practical Secure SDLC)

8.1 Design and change planning

For every new feature or integration:

• Document what customer data is accessed.
• Document whether data leaves the host platform (egress).
• Justify all permissions and scopes.
• Identify security risks (basic threat thinking): spoofing, unauthorized access, data leakage, injection risks.

8.2 Implementation requirements

• Validate and sanitize all external inputs.
• Implement authorization checks for every action and data access.
• Prevent injection vulnerabilities and unsafe deserialization where applicable.
• Do not accept or process untrusted content without safe handling (encoding and sanitization).

8.3 Web and transport security (when there is any external web component)

• Use HTTPS only, with TLS 1.2 or higher.
• Enable HSTS with a minimum age of one year for externally hosted domains, when applicable.
• Use security headers and safe cookie attributes when applicable:
• Secure
• HttpOnly
• SameSite where feasible
• Avoid exposing sensitive information through referrer headers or browser caches.

9. Secrets Management

• Secrets include API tokens, OAuth client secrets, shared secrets, private keys, and encryption keys.
• Secrets must not be stored in:
• Source code repositories
• Build logs
• URLs, query strings, or client-side code
• Approved storage locations:
• GitHub Actions Secrets
• Forge secure storage mechanisms, when applicable
• An approved secret manager controlled by iDev

10. Customer Data Protection and Minimization

• Collect and process only what is necessary to deliver the agreed functionality.
• When customer data is stored outside the vendor platform:
• Encrypt data at rest using strong encryption.
• Apply access controls to restrict data to authorized personnel and systems.
• Keep customer environments segregated:
• Separate configuration and secrets per customer.
• Prevent cross-tenant access by design.

11. Forge and Shared Responsibility

• For Forge apps, iDev follows a shared responsibility model:
• Atlassian operates and secures the Forge platform runtime.
• iDev is responsible for secure code, configuration, access controls, scopes, egress configuration, and operational governance.
• Egress must be explicitly documented and approved as part of design.
• Outbound connections must use HTTPS and TLS 1.2 or higher.

12. Logging and Monitoring

• Logs must never contain:
• API tokens, passwords, or secrets
• Unnecessary personal information
• Logs should support incident investigation:
• Authentication and authorization failures
• Administrative actions
• Configuration changes
• Where feasible, logs should be reviewed periodically and alerts configured for suspicious patterns.

13. Vulnerability Management and Fix Timelines

13.1 Intake

Security issues may be discovered through:

• Internal testing
• Customer reports
• Marketplace or platform notifications
• Automated scanning results

13.2 Triage and remediation timelines

iDev targets the following maximum timeframes for cloud app vulnerabilities after report or triage:

• Critical (CVSS 9.0+): 4 weeks
• High (CVSS 7.0+): 6 weeks
• Medium (CVSS 4.0+): 8 weeks
• Low (CVSS < 4.0): 25 weeks

13.3 Tracking and evidence

Each security issue must have:

• A tracked ticket
• Severity assessment and affected components
• Fix description and link to code changes
• Test evidence or verification notes
• Release date

14. Incident Response

An incident includes suspected or confirmed:

• Unauthorized access
• Data leakage
• Compromised credentials or secrets
• Vulnerability exploitation

Minimum steps:

1. Contain: revoke or rotate affected secrets and restrict access.
2. Assess: determine impact, scope, and affected customers.
3. Eradicate: fix root cause, patch systems, remove malicious access.
4. Recover: validate services and controls, restore safe operations.
5. Learn: document timeline, lessons learned, and preventive actions.

15. Privacy, Retention, and Deletion

• Retain customer data only for as long as needed to provide the service.
• Delete or anonymize data when no longer necessary, unless contractually required to retain.
• If any customer requests deletion under applicable privacy laws or contract terms, iDev follows documented deletion procedures.

16. Third-Party Services

• Any third-party service used to process customer data must be approved by the App Owner and documented.
• Vendors must meet minimum security requirements (MFA, encryption, access controls).

17. Exceptions

• Any exception must be approved by the Policy Owner.
• Exceptions must include:
• Business justification
• Risk assessment
• Compensating controls
• Expiration date

18. Review and Updates

• This policy is reviewed at least annually, or when a major change occurs:
• New app launch
• New egress or hosting model
• New regulatory or platform requirements

Appendix A: Release Security Checklist (one-page)

Before any production release:

• Scopes and permissions are minimized and justified.
• No secrets in code, artifacts, client-side bundles, or logs.
• npm vulnerability scanning has no untriaged critical or high findings.
• Input validation and authorization checks are in place for new endpoints or features.
• HTTPS and TLS 1.2+ are enforced for any external endpoints.
• Egress destinations are documented and approved.
• Logging does not expose sensitive data.
• A rollback plan exists, and release notes are prepared.

Appendix B: Evidence Available Upon Request

• MFA enforcement for GitHub and email
• Branch protection and code review settings on GitHub
• CI logs demonstrating npm audit (or equivalent) execution
• Vulnerability triage and remediation tickets
• Incident response runbook and incident records (when applicable)