Partner Security Policy

How Agilva Solutions secures Link-a-Link, handles vulnerabilities, and responds to security incidents.

Architecture overview

Link-a-Link is built exclusively on the Atlassian Forge platform — Atlassian's serverless, managed runtime for Confluence and Jira apps. The plugin does not operate any independent servers, virtual machines, or databases. All code executes within Atlassian's Forge sandbox with strict tenant isolation enforced at the platform level.

URL mapping data is stored in AWS S3 (eu-west-1, Ireland) with AES-256 encryption at rest and TLS 1.2+ in transit. IntellinQ configurations and plugin settings are stored in Forge Storage, managed entirely by Atlassian.

Key security facts

Version 1.0 · Effective date: 08 April 2026

Infrastructure Security

How the infrastructure running Link-a-Link is secured.

Forge sandbox

All resolver code runs inside Atlassian's isolated Forge runtime, which enforces strict security boundaries between tenants and between the app and the wider internet. Agilva Solutions does not operate any servers, VMs, or databases.

AWS S3 storage

• Region: eu-west-1 (Ireland, European Union)
• Bucket: link-a-link-storage-eu — private, no public access
• Encryption at rest: AES-256 server-side encryption (SSE-S3)
• Encryption in transit: TLS 1.2+
• Backup data: Also encrypted at rest

Lambda processing

CSV files are processed by link-a-link-processor (Lambda, eu-west-1) using least-privilege IAM roles with only the minimum S3 permissions required (GetObject, PutObject on the tenant prefix). No broad S3 access is granted.

Upload mechanism

CSV uploads use time-limited presigned S3 URLs with a 15-minute expiry. These URLs grant access only to the specific tenant's prefix — no additional bucket access is possible.

Access Control

How access to systems and data is controlled.

Tenant isolation

Every workspace that installs Link-a-Link receives a completely isolated data environment. Isolation is enforced at three independent layers:

• Application layer: Every Forge Storage key is namespaced with the workspace's unique tenantId. No query can read across tenant boundaries.
• Platform layer: Forge enforces runtime-level isolation between app instances for different tenants — they cannot share storage, memory, or context.
• S3 layer: Object keys are prefixed with tenantId and IAM policies restrict access to the Lambda function with the correct context.

Forge Context Token (FCT)

Every resolver invocation is validated against Atlassian's FCT mechanism, ensuring the caller is authenticated to the correct workspace before any storage read or write operation takes place.

No credentials in code

AWS credentials are stored as Forge environment variables (production) and never hardcoded in source code.

Admin controls

Only Confluence workspace administrators can upload mapping data, configure IntellinQ systems, and initiate data deletion. End users have read-only search access.

Data Protection

How we protect the data Link-a-Link handles.

No personal data

Link-a-Link is deliberately designed to avoid collecting personal data. The plugin never collects, stores, or transmits:

• User account IDs, names, or email addresses
• Search queries typed by users
• Confluence page content, titles, or attachments
• Passwords, tokens, or session identifiers
• Browser information, IP addresses, or device fingerprints
• Behavioural analytics of any kind

What we do store

Only admin-uploaded and admin-configured data:

• URL mapping index — old DC URLs/PageIDs mapped to new Cloud URLs (no page content, no personal identifiers)
• IntellinQ configurations — system names, URL prefixes, base URLs
• Aggregate search counters — integers only, no query strings
• Technical error logs — error type and message only, max 30 entries, FIFO rotation

Admin-initiated deletion

Administrators can permanently delete all mapping data at any time from the settings panel. Deletion is immediate, irrecoverable, and audit-logged. There is no backup, soft-delete, or archival copy retained.

Support reports

The built-in support report feature generates diagnostic JSON containing only aggregate counts and technical metadata — never personal data, search queries, or page content.

Monitoring & Logging

What we log, what we don't, and how we monitor.

What we log

• Upload timestamps and processing status
• Aggregate search counters (integers only)
• Technical error events (type, message, component name)
• Data deletion events (timestamp and action type only)

What we do not log

• Search queries entered by users
• User account IDs or names
• Credentials, API tokens, or passwords
• Page content or titles
• IP addresses or device information

Log retention

Error event logs are retained with a maximum of 30 entries per tenant using FIFO rotation. Audit log entries are retained indefinitely (max 30 per tenant). All logs are purged on app uninstall per Atlassian's Forge platform policies.

Vulnerability Scanning

How we identify vulnerabilities in our code and dependencies.

Software Composition Analysis (SCA)

We perform SCA — dependency and open-source library scans — to identify known vulnerabilities in our project dependencies. Scan results are reviewed as part of our release process. No release proceeds with known critical or high-severity vulnerabilities in dependencies.

Library management

We ensure the libraries and frameworks used in Link-a-Link are free from known vulnerabilities before including them. Dependencies are regularly reviewed and updated.

OWASP Top 10

We have reviewed and actively design against the OWASP Top 10 most common security risks when building our app.

Bug Fix Policy

How we handle security bugs when they're found.

We follow Atlassian's Marketplace security bug-fix policy, which defines response timelines based on vulnerability severity.

Our bug-fix policy details are aligned with:
Atlassian Marketplace Security Bug Fix Policy

Our commitments

• Critical vulnerabilities are triaged immediately upon report
• Remediation follows Atlassian's required timelines for each severity level
• Patches are deployed through the Atlassian Forge platform
• Affected customers and Atlassian are notified following the vulnerability notification template

Reporting a Vulnerability

How to report a security issue in Link-a-Link.

How to report

For any security concerns, contact us at privacy@agilva.com.

What to include

• A clear description of the vulnerability
• Steps to reproduce (if applicable)
• The potential impact or severity
• Any supporting evidence (screenshots, logs)

Our response

• Acknowledgement: within 2 business days
• Initial assessment: within 5 business days
• Status update: within 10 business days
• Remediation: according to Atlassian's severity-based timelines

Incident Response Plan

What happens when a security incident is detected.

We maintain a comprehensive incident response plan aligned with Atlassian's published guidelines for Marketplace partners:

Atlassian — Preparing for a Security Incident
Atlassian — App Security Incident Management Guidelines

Incident response steps

1. Detection & containment — the affected component is isolated to prevent further impact
2. Assessment — scope, severity, root cause, and potentially affected tenants are identified
3. Notification — Atlassian and affected customers are notified following Atlassian's Security Incident Notification guide
4. Remediation — the root cause is fixed and a patch is deployed through the Forge platform
5. Post-incident review — lessons learned are documented and controls are updated accordingly

Customer Notification

How we communicate security incidents to affected customers.

In the event of a critical vulnerability or security incident affecting Link-a-Link, we will:

1. Notify Atlassian — immediately, following Atlassian's vulnerability notification requirements
2. Notify affected customers — via the Atlassian Marketplace listing, in-app notification where possible, and email to registered admin contacts
3. Publish a post-incident report — describing the incident, its impact, and the remediation steps taken

Our notification process follows Atlassian's published template:
Atlassian — App Vulnerability Notification Template

Communication channels

• Atlassian Marketplace listing (public notice)
• Email to registered workspace admin contacts (where available)
• Direct contact at privacy@agilva.com

Secure Development

How we build and release Link-a-Link safely.

Source control security

• Multi-Factor Authentication (MFA) required for all access to source code management
• Pull requests required to push any change to production code
• Peer approval required on every pull request before merge

Secure coding practices

• OWASP Top 10 reviewed and actively designed against
• Security testing integrated into our development process
• Libraries and frameworks verified free from known vulnerabilities before use
• API keys and secrets managed and rotated periodically
• No credentials in code — all secrets stored as Forge environment variables

Release process

• SCA dependency scans run before every release
• Pull request review includes security review checklist
• Deployments are made through the Atlassian Forge platform

Workstation Security

How developer devices are secured.

• Anti-Virus / Endpoint protection deployed on all development workstations
• Full disk encryption (FDE) enabled on all development workstations
• Patch management process in place to keep operating systems and software up to date
• Multi-Factor Authentication (MFA) required for all accounts accessing company systems
• Strong password policy enforced across all company accounts

Security Contact

How to reach us about security matters.

This Partner Security Policy is published in accordance with Atlassian Marketplace requirements. Version 1.0 · Effective date: 08 April 2026