Consuming and Building Open Source in a Regulated Financial Institution
Consuming and Building Open Source in a Regulated Financial Institution
This domain tests controls around open source intake, supply-chain evidence, and vulnerability response in an environment with audit, third-party risk, and regulatory obligations.
Core rules
- An OSPO or equivalent sets policy: approved license list, intake review, exception process, and records. 'Internal use' can reduce distribution obligations but does not erase security or audit duties.
- Generate an SBOM (SPDX or CycloneDX) and scan dependencies with SCA. Track CVEs with CVSS and exploitability context; define patch SLAs by severity and exposure.
- Use artifact repositories and pinned versions; verify provenance with signatures and SLSA-style attestations where available.
- Copyleft and AGPL need review before distribution or customer-facing network use. Inner source can spread good practice but still follows firm policy.
- Regulators expect third-party risk management, resilience, and records; open source is not a policy-free zone.
Worked example
A team wants a GPLv3 library for an internal-only risk engine. Internal use is generally permitted without distributing source, but the firm still requires security review, SBOM entry, and a maintenance owner. If the same code ships in a client desktop app, distribution triggers source-availability obligations, so legal review is required before release. An AGPL component in a customer-facing SaaS needs even earlier review because network interaction can trigger obligations.
Traps
- Assuming internal use means no obligations at all.
- Treating the SBOM as a one-time release artifact.
- Patching by CVSS score alone without exposure context.
- Forgetting that forks create maintenance and security ownership.
- Letting a team approve its own license exception.