Subresource Integrity (SRI)

While Subresource Integrity (SRI) is a powerful security feature, it isn’t well-suited for environments where JavaScript code is frequently updated - like the Constructor beacon.

Constructor makes regular updates to the beacon code to enhance tracking. This is to ensure the behavioral events pipeline is as strong as possible to maximize result attractiveness, providing to the best impact to outlined business metrics / KPIs.

Implementing SRI would effectively halt Constructor’s ability to iterate on the beacon code, as the version would be “pinned” by the content hash. Maintaining the ability to enhance tracking is critical to integration success. As a result, Constructor prioritizes other security measures in favor of implementing a restrictive SRI policy:

• Constructor has software backed enforcement that at least one engineer must code review and approve any changes to beacon code. It is not possible for a single entity to deploy a change to a beacon.
• The beacon code is built on centralized infrastructure where Constructor maintains full control over the build environment and any software utilized.
• Any software dependencies necessary for the beacon to function are strictly audited and cannot be added without review. Dependency versions are pinned.
• The Constructor beacon code has strong test coverage. A passing test run is required before changes to beacon code can be deployed.