Vulnerability Management & Responsible Disclosure

This document explains how potential security vulnerabilities are prevented, detected, and addressed for Boxcurve Unity, and where responsibility sits for each layer of the solution. It is written for a customer security reviewer assessing how the application is built, released, and supported.

Some elements of vulnerability management are operational commitments Boxcurve makes as the software vendor, for example the security contact channel, the disclosure policy, and fix targets. Application characteristics that can be verified in the shipped solution are stated as fact below. Vendor commitments that are not part of the shipped application are provided by Boxcurve as part of your engagement, and are identified as such.

Shared-responsibility model

Boxcurve Unity is a Microsoft Power Platform application (backed by Microsoft Dataverse) that the customer runs inside their own Microsoft 365 tenant. Vulnerability management is therefore shared across three layers:

Layer	Responsibility	Examples
Microsoft platform (inherited)	Microsoft	Security and patching of Power Platform, Dataverse, Power Automate, and the underlying Azure infrastructure on which they run.
Boxcurve application	Boxcurve	The design, content, and quality of the Boxcurve Unity managed solution, its app, data tables, cloud flows, and security roles.
Customer configuration	Customer	Tenant security posture, identity and access controls, data-loss-prevention policy, connector governance, and the decision of when to apply each Boxcurve Unity update.

Because Boxcurve Unity runs entirely on the Microsoft platform, it inherits the platform's security boundary and Microsoft's platform-patching obligations. The application layer is the part Boxcurve is responsible for, and it is the focus of the sections below.

Application attack surface

A key characteristic of Boxcurve Unity is that it introduces no custom code into the customer's tenant. The application contains:

• no custom-control (PCF) components;
• no plug-ins or .NET assemblies;
• no custom workflow activities; and
• no JavaScript or HTML web resources.

The application is composed of standard Power Platform building blocks, app screens, Dataverse tables, and Power Automate cloud flows, together with their configuration.

The security consequence is that the application's own executable attack surface is minimal. There is no bespoke compiled or scripted code shipped into the tenant in which an application-level code vulnerability could arise, and the application runs within, and inherits the protections of, the Microsoft Power Platform security boundary rather than extending it with custom code.

This does not remove the need for secure configuration: the application's behaviour still depends on how cloud-flow connections, security roles, and tenant policies are configured. Those topics are covered in the Secure Configuration Guidance, Identity & Access Control, and Integrations & Connections documents.

Prevention, pre-release quality and security gates

Boxcurve Unity is built and released through an automated application-lifecycle-management (ALM) pipeline. Each release passes through controlled stages before it can reach a production tenant, and several of those stages act as quality and security gates.

Solution Checker on every build. Every build of the managed solution is automatically scanned by the Power Platform Solution Checker, Microsoft's static analysis tool for Power Platform solutions, configured for the Europe geography. The build classifies findings by severity (Critical, High, Medium, Low, Informational) and fails automatically if any Critical or High severity issue is found, which prevents an affected build from progressing. The full scan results are retained as a build artifact for review.

Managed-only releases. Production and the pre-production environments receive the solution as a managed solution. Managed solutions are locked down: they cannot be edited directly in the target environment and can only be changed by deploying a new version through the pipeline. This protects a deployed environment from unreviewed, ad-hoc modification.

Review and approval gates. Changes reach production only after passing through earlier environments, and deployment to the user-acceptance and production environments requires a manual trigger and an explicit approval before it proceeds. Changes are reviewed before they are merged into the trunk that the pipeline builds from.

Together these gates mean that no Boxcurve Unity change is released to a production tenant without passing automated security/quality scanning and a human approval step.

Detection and remediation

Platform-level vulnerabilities (inherited)

Vulnerabilities in the underlying Power Platform, Dataverse, and Azure services are detected and remediated by Microsoft as part of its operation of those services, independently of any Boxcurve Unity release. Customers do not patch these layers themselves.

For Microsoft's platform security, compliance, and vulnerability-handling evidence, including audit reports available through the Microsoft Service Trust Portal, see Microsoft's documentation:

• Power Platform security and compliance: https://learn.microsoft.com/power-platform/admin/security/
• Microsoft Service Trust Portal: https://servicetrust.microsoft.com/

Application-level fixes (Boxcurve)

Because the application contains no custom code, application-level issues are addressed by changing the standard configuration of the app, its tables, or its cloud flows, and re-releasing the managed solution through the pipeline described above. Fixes are therefore subject to the same automated scanning, approval, and managed-release controls as any other change.

Updates are delivered to the customer as managed-solution releases. The customer applies each release on their own schedule; Boxcurve does not push changes into a customer's production tenant automatically. Update and change-management mechanics are described in the Updates & Change Management document.

Application fix targets

Target timeframes for acknowledging, triaging, and releasing fixes for confirmed application-level vulnerabilities, including severity-based response and remediation targets, are a Boxcurve operational commitment set out in your support agreement with Boxcurve.

Responsible disclosure

Boxcurve welcomes reports of suspected security vulnerabilities in Boxcurve Unity so they can be investigated and resolved through the controlled release process described above.

Disclosure channel and policy

Report a suspected vulnerability to Boxcurve through your support channel. Boxcurve operates a responsible-disclosure process as part of your engagement, covering:

• the security contact through which a reviewer or customer reports a suspected vulnerability;
• the disclosure policy, including scope, acknowledgement timeframe, and coordinated-disclosure handling;
• the process for tracking and communicating confirmed issues to affected customers.

Independent testing and attestation

Penetration testing and attestation

An independent security attestation for Boxcurve Unity is in progress. The scope and cadence of independent penetration testing, and the current attestation status and results, are provided by Boxcurve on request as part of your engagement.

Customer responsibilities

The customer's tenant configuration is the third layer of the shared-responsibility model and is managed by the customer, not by Boxcurve. To reduce the overall risk surface around Boxcurve Unity, the customer is responsible for:

• applying Boxcurve Unity managed-solution updates on a timely schedule appropriate to their risk appetite;
• configuring least-privilege access and reviewing it periodically (see Secure Configuration Guidance and Identity & Access Control);
• governing the connectors and connections that Boxcurve Unity uses for its integrations (see Integrations & Connections); and
• operating tenant-level platform controls such as Conditional Access and data-loss-prevention (DLP) policy.

Platform controls

Conditional Access and data-loss-prevention are tenant-level platform controls provided by Microsoft Entra ID and the Power Platform, not features of Boxcurve Unity. They are configured and operated by the customer. For guidance, see Microsoft's documentation:

• Power Platform data-loss-prevention policies: https://learn.microsoft.com/power-platform/admin/wp-data-loss-prevention
• Microsoft Entra Conditional Access: https://learn.microsoft.com/entra/identity/conditional-access/

Summary

Question	Position
How are vulnerabilities prevented?	No custom code is shipped into the tenant; every managed build is scanned by Solution Checker and fails on Critical/High findings; releases are managed-only and gated by review and manual approval.
How are vulnerabilities found?	Platform issues are detected and fixed by Microsoft (inherited). Application issues are addressed by re-releasing standard configuration through the gated pipeline. Independent attestation is in progress.
How are vulnerabilities disclosed?	Through Boxcurve's responsible-disclosure process; report suspected vulnerabilities to Boxcurve through your support channel.