CAIQ-Lite security self-assessment

Context: shared responsibility

This is the single most important frame for reading the answers below.

FastGantt is a 100% Atlassian Forge app. Nirama Solutions operates no servers, no databases, no networks, no datacenters, and no customer-facing infrastructure of any kind. Specifically:

• All application code runs on Atlassian's Forge platform (managed, serverless) inside the customer's own Atlassian tenant.
• All application data is stored in Forge hosted storage in the customer's tenant — Forge SQL for the issue projection, dependency scheduling metadata and saved baselines; Forge KVS for sync state and per-user view preferences. Nirama Solutions holds no copy of customer data and has no API or backdoor to read it.
• Unlike our other apps, FastGantt caches customer issue CONTENT. To draw a 10,000-task plan in seconds it keeps a projection of the Jira issues in the projects where it is used: for each issue, the key and the fields mapped for the timeline (summary, status, dates, estimates, issue links, issue type, assignee). Every value in it derives from data already in the customer's Jira, it is refreshed from Jira automatically, and it is deleted on uninstall. This is the one place where FastGantt's data-at-rest answers differ from every other Nirama app, and it is stated plainly rather than buried.
• The only personal data the app stores is the Atlassian account ID: the assignee of a cached issue, and the key under which a user's own view preferences are saved. It stores no display names, no email addresses, no avatar URLs and no time zones — Jira returns all of those with every user field, and the app strips them before writing (src/personalData.js), resolving names and faces live from Jira, with the viewer's permissions, each time a plan is opened. Because an account ID is personal data under Atlassian's User Privacy Developer Guide, the app reports the accounts it holds through the Forge Privacy API on Atlassian's cycle and erases an account's data as soon as Atlassian reports it closed.
• The app declares no egress permissions. It cannot send data to any external destination, and it exposes no inbound HTTP endpoints (verified with forge eligibility: the app is eligible for Atlassian's Runs on Atlassian program, which requires exactly this).
• The only data Nirama Solutions receives is diagnostic error logging surfaced by Atlassian in the developer console (deliberately sparse; never contains field names, descriptions, or account IDs) and aggregate operational metrics provided by Atlassian.
• The app writes to customer issues, which most Forge apps do not: rescheduling a task changes the mapped Jira date fields, and the app can create issues and issue links. Every one of those writes is made as the signed-in user from the app's iframe, so Jira independently enforces that user's own permissions — a user without "Edit issues" gets a refusal the app explains in words. The app declares no delete: scope and deletes no issue. Changes are reversible in the app itself (undo/redo writes the previous values back to Jira), and a read-only mode is available per project.
• One elevated path, disclosed rather than hidden. The background sync reads a project's issues with app permission (asApp) to build one cache per project instead of one per viewer. Access to that cache is gated on a per-caller BROWSE_PROJECTS check that fails closed, so no one can read a project they cannot open — but Jira issue-level security distinctions between members of the same project are not re-applied per viewer. Admins who use issue security levels should take that into account; it is published on our security page and in the listing.

Consequently, controls covering infrastructure, encryption implementation, key management, physical security, network security, backups and disaster recovery are inherited from Atlassian, whose own certifications (SOC 2, ISO 27001 and others) are published at https://www.atlassian.com/trust. Those questions are answered N/A with a pointer, not left blank.

What is in Nirama Solutions' control, and therefore genuinely assessed here: secure development practice, application-level authorization and data handling, personal-data handling, access control to the source repository and developer console, incident response, and endpoint hygiene.

AIS — Application & Interface Security

AIS-01.2 — Do you use an automated source code analysis tool to detect security defects in code prior to production?

Yes. Two automated scans run on every push and pull request to main, and weekly on a schedule (.github/workflows/security.yml):

• SAST — Semgrep with the p/javascript, p/typescript and p/secrets rulesets; the job fails on any finding. Latest result: 112 rules over 59 files, 0 findings.
• SCA — npm audit across both package trees. Anything that ships must be clean and the job blocks on it; dev-only tooling is reported without blocking. Latest result: 0 vulnerabilities in shipped dependencies (Forge backend and Custom UI production deps). Dependabot (.github/dependabot.yml) additionally opens weekly update PRs and security alerts.

In addition, every change is type-checked with TypeScript in strict mode, validated with forge lint, and covered by 52 automated tests including a backend suite for the authorization, anonymization and visibility-gating seams. CodeQL is not used because code scanning requires GitHub Advanced Security on private repositories.

AIS-01.5 — Do you review your applications for security vulnerabilities and address any issues prior to deployment to production?

Yes. Repository conventions require a code review and, for security-relevant work, a security review before a change is considered done. Findings are fixed before release. Examples of issues found and fixed by this process in this app: a cross-store inconsistency where the sync state claimed a cache the database did not have, so the app rendered nothing; a paging path that could have rendered a partial plan with no error shown; a licence gate that read the licence from an undocumented location and so would have failed open; an erasure loop that could not terminate when one account ID was a prefix of another; and storage of assignee display names, avatar URLs and time zones where an account ID sufficed.

AIS-02.1 — Are all identified security, contractual, and regulatory requirements for customer access contractually addressed and remediated prior to granting customers access to data, assets, and information systems?

Yes. Customer use is governed by the Atlassian Marketplace Terms of Use plus our published Terms of Service and Privacy Policy. All app permissions are declared as Forge scopes in the manifest and must be explicitly consented to by a site administrator at install time.

AIS-03.1 — Do your data management policies and procedures require audits to verify data input and output integrity routines?

Partial. Input validation and authorization are enforced server-side (not merely in the UI) and are covered by automated tests that run on every change: every project-scoped resolver re-checks the caller's Jira BROWSE_PROJECTS permission per call (and EDIT_ISSUES for writes) rather than trusting that the page rendered; the project is taken from the invocation context, never from the payload, so one project's user cannot reach another project's cache; stored records are rebuilt field by field from validated values, with strings capped, enums whitelisted and numbers clamped; and every SQL value is bound, never interpolated. In addition, a manifest contract test pins the declared scope list and fails the build on any egress permission, webtrigger or display condition. There is no separate formal audit programme performing this verification independently.

AAC — Audit Assurance & Compliance

AAC-02.1 — Do you allow tenants to view your SOC2/ISO 27001 or similar third-party audit or certification reports?

No. Nirama Solutions holds no third-party security certification. The platform that hosts and stores all customer data (Atlassian Forge) is covered by Atlassian's own SOC 2 / ISO 27001 programme, published at https://www.atlassian.com/trust.

AAC-02.2 — Do you conduct network penetration tests of your cloud service infrastructure at least annually?

N/A. Nirama Solutions operates no network infrastructure. Penetration testing of the Forge platform is performed by Atlassian.

AAC-02.3 — Do you conduct application penetration tests of your cloud infrastructure regularly as prescribed by industry best practices and guidance?

No. No third-party application penetration test has been performed to date. Compensating factors: the app has no externally reachable attack surface (no egress, no inbound endpoints, no public API, and deliberately no web trigger); authentication and tenant isolation are enforced by the Forge platform; identity is always derived server-side from the request context and never accepted from the client; the mutation surface is two reversible endpoints which run asUser so Jira enforces the caller's own administrator permission independently of the app's own check; the app has no hard-delete capability; and adversarial code review is part of the development process (three rounds to date, all findings addressed). See Gaps (Marketplace Bug Bounty).

AAC-03.1 — Do you have a program in place that includes the ability to monitor changes to the regulatory requirements in relevant jurisdictions, adjust your security program for changes to legal requirements, and ensure compliance with relevant regulatory requirements?

Partial. Atlassian Marketplace and Forge policy changes are tracked actively (they gate the ability to ship), and GDPR obligations are addressed in the published privacy policy. There is no formal, documented regulatory-monitoring programme.

BCR — Business Continuity Management & Operational Resilience

BCR-02.1 — Are business continuity plans subject to testing at planned intervals or upon significant organizational or environmental changes to ensure continuing effectiveness?

No. No formal business continuity plan is maintained. Rationale: service availability is a function of Atlassian's platform, and the app holds no state outside Forge storage. All source code, configuration and build tooling is in version control, so the app can be rebuilt and redeployed from scratch in minutes by any authorized developer.

BCR-10.1 — Are policies and procedures established and made available for all personnel to adequately support services operations' roles?

Yes (proportionate to a single-person team). Operational procedures are documented in the repository: an operations and monitoring runbook (docs/OPERATIONS.md) covering where signals live, the customer log-sharing model, a debug order for customer reports, and logging hygiene rules; plus repository conventions covering review, testing and platform practice.

BCR-11.1 — Do you have technical capabilities to enforce tenant data retention policies?

Partial. The issue projection is a cache, not an archive: it is refreshed from Jira, rows for issues that leave scope are pruned, and it holds nothing that is not already in the customer's Jira. It therefore has no retention window — it lives as long as the app is installed and is deleted on uninstall, when all access ends and Atlassian removes app storage per the Forge data lifecycle. Saved baselines are deliberately kept until deleted by a user (a baseline records a commitment; expiring one silently would lose the thing being compared against), capped at five per project. Personal data has its own lifecycle: account IDs are erased when Atlassian reports the account closed. Retention is not per-tenant configurable.

BCR-11.3 — Have you implemented backup or recovery mechanisms to ensure compliance with regulatory, statutory, contractual or business requirements?

N/A (inherited). Application data resides solely in Forge hosted storage; durability and backup are Atlassian platform responsibilities. Nirama Solutions holds no copy of customer data and therefore performs no backups of it.

BCR-11.7 — Do you test your backup or redundancy mechanisms at least annually?

N/A (inherited). See BCR-11.3.

CCC — Change Control & Configuration Management

CCC-04.1 — Do you have controls in place to restrict and monitor the installation of unauthorized software onto your systems?

Partial. The production runtime is Atlassian-managed; code can only reach it through an authenticated forge deploy performed by an authorized developer, and every deployment is versioned and recorded by Atlassian. Application dependencies are pinned in lockfiles and reviewed on change. The development workstation has full-disk encryption (FileVault), an automatic screen lock, and automatic OS and browser updates (confirmed 2026-08-30).

DSI — Data Security & Information Lifecycle Management

DSI-03.1 — Do you provide standardized (e.g. ISO/IEC) non-proprietary encryption algorithms (3DES, AES, etc.) to tenants?

N/A (inherited). The app implements no cryptography of its own. Encryption in transit (TLS) and at rest is provided by the Atlassian Forge platform using Atlassian's standard, industry-accepted implementations.

DSI-03.2 — Do you utilize open encryption methodologies any time your infrastructure components need to communicate with each other via public networks?

N/A (inherited). There are no Nirama-operated components. All communication is between the Forge runtime and Atlassian product APIs over Atlassian-managed TLS. The app declares no egress and communicates with no external systems.

DSI-05.1 — Do you have procedures in place to ensure production data shall not be replicated or used in non-production environments?

Yes. The app runs in three separate Forge environments (development, staging, production), each with isolated storage; no mechanism exists to copy data between them. Development and testing run against a dedicated Atlassian test site with synthetic projects, never against customer data.

DSI-07.1 — Do you support the secure deletion (e.g., degaussing/cryptographic wiping) of archived and backed-up data?

N/A (inherited). Nirama Solutions maintains no archives or backups of customer data. Deletion is performed by the platform.

DSI-07.2 — Can you provide a published procedure for exiting the service arrangement, including assurance to sanitize all computing resources of tenant data?

Yes. Uninstalling the app immediately ends all app access to tenant data, and Atlassian removes app storage in line with the Forge data lifecycle. This is stated in our published privacy policy. As Nirama Solutions never holds a copy, no vendor-side sanitization is required.

DCS — Datacenter Security

DCS-01.2 — Do you maintain a complete inventory of all of your critical assets located at all sites and their assigned ownership?

Partial / N/A. Nirama Solutions operates no datacenters or server sites. The asset inventory consists of the source repository, the Atlassian developer console account, the domain/DNS and static-site hosting account, and developer workstations — all owned by the company principal.

DCS-02.1 — Are physical security perimeters implemented for all areas housing sensitive data and information systems?

N/A (inherited). All customer data resides in Atlassian datacenters, covered by Atlassian's physical security programme.

DCS-09.1 — Do you restrict physical access to information assets and functions by users and support personnel?

N/A (inherited) for customer data. Developer workstations are under the sole physical control of the principal, with full-disk encryption (FileVault) and an automatic screen lock (confirmed 2026-08-30).

EKM — Encryption & Key Management

EKM-02.1 — Do you have a capability to allow creation of unique encryption keys per tenant?

N/A (inherited). Key management is entirely platform-provided; the app neither generates, holds, nor manages cryptographic keys.

EKM-03.1 — Do you encrypt tenant data at rest (on disk/storage) within your environment?

Yes (inherited). All application data is stored in Forge hosted storage, which Atlassian encrypts at rest. The app stores customer data nowhere else.

GRM — Governance and Risk Management

GRM-01.1 — Do you have documented information security baselines for every component of your infrastructure?

Partial. There is no infrastructure to baseline. Application-level security baselines are documented and enforced in the repository: least-privilege scope declarations with per-scope justification in the manifest, a prohibition on adding egress permissions or inbound web triggers, server-side derivation of identity and scope, and a requirement that integrity rules be enforced (and tested) server-side.

GRM-06.1 — Are your information security policies and procedures made available to all impacted personnel and business partners, authorized by accountable business role/function?

Partial. Development and operational practices are documented in the repository and available to all contributors; customer-facing privacy and terms are published on the company website and authorized by the company principal. There is no formal ISMS policy set.

GRM-07.1 — Is a formal disciplinary or sanction policy established for employees who have violated security policies and procedures?

No. Nirama Solutions currently has no employees. This control becomes applicable on first hire.

GRM-09.1 — Do you notify your tenants when you make material changes to your information security and/or privacy policies?

Yes. The published privacy policy carries a "last updated" date and commits to updating the page for material changes; app changes are communicated through Marketplace release notes.

GRM-09.2 — Do you perform, at minimum, annual reviews to your privacy and security policies?

Yes (committed). Policies were published 2026-07-28; the principal has committed to an annual review, next due 2027-07-28 (confirmed 2026-08-30).

HRS — Human Resources

HRS-01.1 — Upon termination of contract or business relationship, are employees and business partners adequately informed of their obligations for returning organizationally-owned assets?

N/A. No employees or contractors to date. Applicable on first hire.

HRS-02.1 — Pursuant to local laws, regulations, ethics, and contractual constraints, are all employment candidates, contractors, and involved third parties subject to background verification?

N/A. No employees or contractors to date. Applicable on first hire.

HRS-03.1 — Do your employment agreements incorporate provisions and/or terms in adherence to established information governance and security policies?

N/A. See HRS-02.1.

HRS-04.1 — Are documented policies, procedures, and guidelines in place to govern change in employment and/or termination?

N/A. See HRS-02.1.

HRS-09.5 — Are personnel trained and provided with awareness programs at least once a year?

Partial. No formal awareness programme exists (single-person company). The principal maintains current working knowledge of Atlassian platform security requirements, Forge security practice, and secure application development.

IAM — Identity & Access Management

IAM-01.1 — Do you restrict, log, and monitor access to your information security management systems?

Yes. The systems in scope are the source repository (GitHub, private), the Atlassian developer console, and the DNS/static-hosting account (Cloudflare). Access is limited to the company principal; multi-factor authentication is enabled on all three, credentials are held in a password manager with a unique password per service, and each platform enforces authentication and maintains its own access logs (confirmed 2026-08-30).

IAM-01.2 — Do you monitor and log privileged access (e.g., administrator level) to information security management systems?

Partial (inherited). Privileged access is logged by the underlying platforms (GitHub audit log, Atlassian account/admin logs). No additional aggregation is performed.

IAM-02.1 — Do you have controls in place ensuring timely removal of systems access that is no longer required for business purposes?

Yes. There is no standing third-party or contractor access to remove; access is limited to the principal and reviewed when circumstances change.

IAM-04.1 — Do you manage and store the identity of all personnel who have access to the IT infrastructure, including their level of access?

Yes. One identity, with full access, documented here.

IAM-06.1 — Are controls in place to prevent unauthorized access to your application, program, or object source code?

Yes. Source is held in a private GitHub repository restricted to the owner, with multi-factor authentication enabled (confirmed 2026-08-30). No credentials or tokens are committed: registry and environment files (.npmrc, .env*) are excluded by .gitignore, and the repository has been verified to contain no secrets.

IAM-06.2 — Are controls in place to prevent unauthorized access to tenant application, program, or object source code?

N/A. Nirama Solutions holds no tenant source code.

IAM-08.1 — Do you document how you grant, approve and enforce access restrictions to tenant/customer credentials following the rules of least privilege?

N/A / Yes by design. Nirama Solutions never receives, stores, or has access to customer credentials. All product access happens through Forge platform tokens, constrained to the app's declared scopes and to what the installing administrator consented to. Scope selection is deliberately least-privilege and justified per scope in the manifest.

IAM-10.1 — Do you require a periodical authorization and validation of the entitlements for all system users and administrators?

Yes (annual). A single account set. The principal has committed to reviewing it annually (confirmed 2026-08-30).

IAM-11.1 — Is timely deprovisioning, revocation, or modification of user access upon any change in status implemented?

Yes / N/A. No additional users exist; the process applies on first hire.

IVS — Infrastructure & Virtualization Security

IVS-01.1 — Are file integrity (host) and network intrusion detection (IDS) tools implemented to help facilitate timely detection, investigation and response to incidents?

N/A (inherited). No hosts or networks are operated by Nirama Solutions; Forge is a managed serverless runtime with no vendor-controlled OS or network layer.

IVS-01.2 — Is physical and logical user access to audit logs restricted to authorized personnel?

Yes (platform-enforced). Application logs are accessible only to authorized developers of the app through the Atlassian developer console. Customers additionally control whether their site's logs are shared, and can revoke that at any time in Atlassian Administration.

IVS-01.5 — Are audit logs reviewed on a regular basis for security events (e.g., with automated tools)?

Partial. Error logs and operational metrics are reviewed as part of the documented operations process, and the application is instrumented so that unexpected exceptions (server and client) are logged with an operation label. There is no automated SIEM correlation or alerting.

IVS-03.1 — Do you use a synchronized time-service protocol (e.g., NTP) to ensure all systems have a common time reference?

N/A (inherited). Time is provided by the Atlassian platform runtime.

IVS-07.1 — Are operating systems hardened to provide only the necessary ports, protocols, and services to meet business needs?

N/A (inherited). No vendor-controlled operating systems. Notably, the app exposes no inbound ports or HTTP endpoints at all: the only web trigger ever used (a temporary internal utility) was removed precisely because an inbound endpoint is treated as a potential egress path.

IVS-08.1 — For your SaaS or PaaS offering, do you provide tenants with separate environments for production and test processes?

Yes. Forge provides development, staging and production environments, each independently deployed and with isolated storage.

IVS-08.3 — Do you logically and physically segregate production and non-production environments?

Yes (logical, platform-enforced). Separate Forge environments with separate storage; physical segregation is an Atlassian platform concern.

IVS-09.1 — Are system and network environments protected by a firewall or virtual firewall?

N/A (inherited). Network protection is provided by the Atlassian platform.

IVS-11.1 — Do you restrict personnel access to all hypervisor management functions or administrative consoles based on the principle of least privilege?

N/A (inherited). No hypervisor or infrastructure console is operated by Nirama Solutions.

IVS-12.1 — Are policies and procedures established and mechanisms configured to protect the wireless network environment perimeter?

N/A. No corporate network or wireless infrastructure. Development occurs on a private network secured with WPA2/WPA3 (confirmed 2026-08-30).

IVS-12.2 — Are policies and procedures established and mechanisms implemented to ensure wireless security settings are enabled with strong encryption?

N/A. See IVS-12.1.

IVS-12.3 — Are policies and procedures established to protect wireless network environments and detect the presence of unauthorized (rogue) network devices?

N/A. See IVS-12.1.

IPY — Interoperability & Portability

IPY-01.1 — Do you publish a list of all APIs available in the service and indicate which are standard and which are customized?

Partial. The app exposes no public or customer-callable API. It consumes documented Atlassian REST APIs, and every Atlassian permission it uses is declared with justification in the app manifest. Customer data portability is provided through built-in CSV export of the task list, generated client-side; and in any case every value the app holds originates in the customer's own Jira, which remains the system of record and can be exported by Jira's own means.

MOS — Mobile Security

MOS-03.1 — Do you have a policy enforcement capability to ensure that only approved applications can be loaded onto a mobile device?

No. No mobile device management is in place (confirmed 2026-08-30); no customer data is stored on mobile devices, and no mobile device is used to administer the service.

SEF — Security Incident Management, E-Discovery & Cloud Forensics

SEF-02.1 — Do you have a documented security incident response plan?

Yes. A documented plan is maintained in docs/OPERATIONS.md (Security incident response), aligned to Atlassian's app security incident management guidelines: the definition of an incident; investigation steps (root cause, data impact, duration, affected users and data types); mandatory notification to Atlassian as a P1 ticket within 24 hours with status updates at least every 6 hours during remediation; containment options up to temporarily delisting the app; remediation with a regression test; customer notification within 72 hours plus supervisory-authority notification for personal-data breaches; and a post-incident review. Remediation deadlines follow Atlassian's Security Bug Fix Policy CVSS service levels. A customer-facing summary is published at https://niramasolutions.com/security#incident-response.

SEF-02.4 — Have you tested your security incident response plans in the last year?

No. No incident-response exercise has been conducted.

SEF-03.1 — Are workforce personnel and external business relationships adequately informed of their responsibility to report all information security events?

Yes (proportionate). A public support channel is published on the company website and Marketplace listing, and the contact page explicitly invites bug reports with reproduction detail.

SEF-03.2 — Do you have predefined communication channels for workforce personnel and external business partners to report incidents in a timely manner?

Yes. support@niramasolutions.com, published on the contact page, the privacy policy and the Marketplace listing, with a stated response target of two business days.

SEF-04.4 — Do you enforce and attest to tenant data separation when producing data in response to legal subpoenas?

N/A. Nirama Solutions holds no tenant data and is technically unable to produce it. Such requests must be directed to Atlassian, which hosts the data, or to the customer, who controls it.

STA — Supply Chain Management, Transparency & Accountability

STA-02.1 — Do you make security incident information available to all affected customers and providers through electronic methods?

Yes. Affected customers would be notified by email to their site contact and, where broadly relevant, through the Marketplace listing; breach notification is committed to in the published privacy policy.

STA-03.1 — Do you collect capacity and use data for all relevant components of your cloud service offering?

Partial (inherited). Atlassian provides invocation counts, error rates and latency for the app in the developer console. Nirama Solutions collects no independent telemetry or analytics of its own — there is no egress path by which it could.

STA-05.4 — Do third-party agreements include provision for the security and protection of information and assets?

Yes. The only subprocessor material to customer data is Atlassian (platform, storage, Marketplace billing), governed by Atlassian's terms and certifications. The static marketing website is hosted by Cloudflare, which also forwards support@ and security@; Cloudflare receives no customer data. Those mailboxes are hosted by Microsoft, which is therefore a sub-processor for the controller-role data — support and security correspondence — and receives no customer app data. There is no analytics, no CRM and no helpdesk product. No other third party receives customer data (confirmed 2026-08-30).

STA-05.5 — Do you have the capability to recover data for a specific customer in the case of a failure or data loss?

No (by design). Nirama Solutions holds no copy of customer data and therefore cannot restore it. Data durability and recovery are Atlassian platform functions. This is a deliberate privacy trade-off and is disclosed in the privacy policy.

STA-07.4 — Do you provide tenants with ongoing visibility and reporting of your operational Service Level Agreement (SLA) performance?

No. No separate SLA reporting is offered. Because the app runs entirely on Atlassian's platform, its availability tracks Atlassian's, which customers can monitor at https://status.atlassian.com.

STA-09.1 — Do you mandate annual information security reviews and audits of your third party providers?

Partial. Nirama Solutions relies on the published certifications and trust documentation of its providers (principally Atlassian) and reviews them; it performs no independent audits of them.

TVM — Threat and Vulnerability Management

TVM-01.1 — Do you have anti-malware programs installed on all of your IT infrastructure network and systems components?

N/A (inherited) / Partial. No servers or infrastructure are operated. Developer workstations rely on the macOS platform protections — Gatekeeper, XProtect and System Integrity Protection — with no third-party endpoint security product (confirmed 2026-08-30).

TVM-02.5 — Do you have a capability to patch vulnerabilities across all of your computing devices, applications, and systems?

Yes. Operating system and browser updates install automatically on developer workstations (confirmed 2026-08-30). Runtime patching of the Forge platform is performed by Atlassian. Application dependencies are pinned in lockfiles, updated on review, and a fix can be built, tested and deployed to production within minutes via forge deploy — no coordinated customer upgrade is required, since all customers run the same deployed version.

TVM-03.1 — Is mobile code authorized before its installation and use, and the code configuration checked?

Yes. The only client-side code is the app's own Custom UI bundle, built from reviewed source in version control and served by Atlassian from the app's static resources. No third-party scripts, fonts, CDNs, analytics or trackers are loaded — the app's Content Security Policy posture and its lack of egress prevent it.

Gaps and recommended next steps

These are the honest No / Partial answers, and what would close them. Publishing them as-is is fine and normal for a small vendor; several are cheap to fix and would meaningfully strengthen the assessment.

About this assessment

This is a self-assessment. It has not been audited or verified by a third party, and Nirama Solutions holds no security certification of its own — the security policy says the same. Every No and Partial above is published as written rather than softened, because an assessment that admits nothing tells you nothing.

Questions, or a request for this in the official CSA workbook format: security@niramasolutions.com.