1. Purpose
The Open-Source Software Register provides a centralized inventory of open-source software components used by the organization.
The register helps the organization:
- Identify open-source components in use
- Record exact versions
- Identify applicable licenses
- Track applications using each component
- Identify direct and transitive dependencies
- Record license-review status
- Track security status
- Record ownership and accountability
- Track license obligations
- Support SBOM management
- Support vulnerability management
- Support software license compliance
- Provide audit evidence
Core Principle
Discover → Identify → Verify → Record → Review → Approve → Monitor → Update → Retire
2. When to Use
Maintain the register when the organization uses open-source software in:
- Production applications
- SaaS platforms
- Websites
- APIs
- Mobile applications
- Internal applications
- Development environments
- Testing environments
- CI/CD pipelines
- Infrastructure
- Cloud environments
- Containers
- Operating systems
- Security tools
- AI/ML applications
- Developer tools
The level of detail should be proportionate to the organization’s risk and software environment.
3. Register Information
| Field | Details |
|---|---|
| Register Name | Open-Source Software Register |
| Organization | |
| Register Owner | |
| Technical Owner | |
| Security Owner | |
| Legal/Compliance Owner | |
| Version | |
| Effective Date | |
| Last Review Date | |
| Next Review Date | |
| Approved By |
4. Master Open-Source Software Register
Maintain one record for each significant component.
| OSS ID | Component | Version | License | Application | Owner | Review Status | Risk |
|---|---|---|---|---|---|---|---|
| OSS-001 | |||||||
| OSS-002 | |||||||
| OSS-003 |
Review Status
- Pending Review
- Under Review
- Approved
- Approved with Conditions
- Restricted
- Remediation Required
- Not Approved
- Retired
5. Component Identification
| Field | Details |
|---|---|
| OSS ID | |
| Component Name | |
| Package Name | |
| Version | |
| Package Ecosystem | |
| Repository | |
| Package Source | |
| Maintainer | |
| Organization/Project | |
| Release Date | |
| Direct/Transitive | |
| Application |
Examples of package ecosystems:
- npm
- PyPI
- Maven
- NuGet
- RubyGems
- Go Modules
- Cargo
- Composer
- Linux packages
- Container images
6. License Information
Record the license applicable to the exact version being used.
| OSS ID | License Name | Version | SPDX ID | License Evidence | Verification Date |
|---|---|---|---|---|---|
License Verification
☐ License identified
☐ Exact version verified
☐ LICENSE/COPYING file reviewed
☐ Package metadata reviewed
☐ Repository verified
☐ License ambiguity assessed
7. License Category
| OSS ID | License Category | License |
|---|---|---|
| Permissive | ||
| Weak Copyleft | ||
| Strong Copyleft | ||
| Network/Service Copyleft | ||
| Public Domain/Equivalent | ||
| Dual License | ||
| Custom/Other |
The category is for management purposes only. Actual license terms should be reviewed where necessary.
8. Application Register
Identify where each component is used.
| OSS ID | Application | Repository | Environment | Purpose | Production? |
|---|---|---|---|---|---|
| Development | |||||
| Testing | |||||
| Production |
9. Direct and Transitive Dependencies
Identify whether the component is directly included or introduced through another dependency.
| OSS ID | Dependency Type | Parent Component | Dependency Path | Application |
|---|---|---|---|---|
| Direct | ||||
| Transitive |
Dependency Type
☐ Direct
☐ Transitive
☐ Build dependency
☐ Development dependency
☐ Runtime dependency
☐ Test dependency
10. Software Version
Record the exact version used.
| OSS ID | Current Version | Latest Approved Version | Version Pinning | Upgrade Status |
|---|---|---|---|---|
Version Controls
☐ Version recorded
☐ Version controlled
☐ Lock file used where appropriate
☐ Upgrade process defined
☐ Unsupported version identified
☐ Security updates monitored
Avoid relying only on a package name without recording the version.
11. Source and Provenance
Record where the component was obtained.
| OSS ID | Source | Repository | Package Registry | Verified |
|---|---|---|---|---|
Possible sources include:
- Official project repository
- Official package registry
- Organization-approved mirror
- Container registry
- Operating-system repository
Provenance Checks
☐ Source verified
☐ Maintainer verified
☐ Package name verified
☐ Version verified
☐ Integrity considered
☐ Suspicious package indicators checked where appropriate
12. Business Purpose
Document why the component is used.
| OSS ID | Component | Business/Technical Purpose | Criticality |
|---|---|---|---|
Examples:
- Web framework
- Authentication
- Database connectivity
- Encryption
- Logging
- API processing
- Data transformation
- UI development
- Testing
- Monitoring
13. Criticality
Classify the importance of the component.
☐ Low
☐ Medium
☐ High
☐ Critical
Consider:
- Production use
- Customer impact
- Business dependency
- Security function
- Data processing
- Availability dependency
- Difficulty of replacement
- Number of applications affected
14. License Review
| OSS ID | License Review Date | Reviewer | Review Result | Evidence |
|---|---|---|---|---|
Review Result
☐ Approved
☐ Approved with Conditions
☐ Further Review Required
☐ Legal Review Required
☐ Remediation Required
☐ Not Approved
15. License Obligations
Record identified obligations.
| OSS ID | Obligation | Applicable | Required Action | Status |
|---|---|---|---|---|
| Copyright Notice | ||||
| Attribution | ||||
| License Notice | ||||
| NOTICE File | ||||
| Source Availability | ||||
| Modification Notice | ||||
| Other |
Do not assume that every open-source component has the same obligations.
16. Distribution Model
Record how the software is used or distributed.
| OSS ID | Internal Use | SaaS | Binary Distribution | Source Distribution | Customer Product |
|---|---|---|---|---|---|
Distribution Status
☐ Internal only
☐ Hosted service/SaaS
☐ Distributed to customers
☐ Distributed to suppliers
☐ Embedded in product
☐ Mobile distribution
☐ Container distribution
17. Modification Status
| OSS ID | Modified? | Modification Description | Forked? | Distributed? |
|---|---|---|---|---|
Status
☐ No modification
☐ Configuration only
☐ Modified source
☐ Forked
☐ Patch applied
☐ Custom version
18. Security Status
Track the security condition of the component.
| OSS ID | Vulnerability Scan | Known Vulnerabilities | Severity | Supported Version | Security Status |
|---|---|---|---|---|---|
Security Status
☐ No known significant issue
☐ Vulnerability identified
☐ Patch available
☐ Remediation in progress
☐ Compensating control
☐ Unsupported
☐ Security review required
19. Vulnerability Reference
Where vulnerabilities are identified:
| OSS ID | Vulnerability ID | Severity | Affected Version | Fixed Version | Action | Status |
|---|---|---|---|---|---|---|
Examples of vulnerability identifiers may include vendor advisories or public vulnerability identifiers.
20. Maintenance Status
Assess whether the open-source project remains actively maintained.
| OSS ID | Project Status | Last Release | Maintainer Activity | Security Support | Assessment |
|---|---|---|---|---|---|
Status
☐ Active
☐ Limited Activity
☐ Inactive
☐ Archived
☐ Unknown
An acceptable license does not automatically mean that a component is suitable from a security or operational perspective.
21. Software Bill of Materials
Where an SBOM exists:
| Application | SBOM Location | Version | Generated Date | Owner | Status |
|---|---|---|---|---|---|
The SBOM may be the detailed source for component inventory while this register maintains the governance-level record.
22. Automated Discovery
Open-source components may be identified through:
☐ SCA tools
☐ SBOM generation
☐ Package managers
☐ Dependency files
☐ Container scanning
☐ Repository scanning
☐ Build pipelines
☐ Software inventory
☐ Developer declaration
☐ Security scanning
Discovery Tool
Tool: __________________________
Last Scan: ______________________
Owner: _________________________
23. License Scanning
Where automated license scanning is available:
| Scan Date | Application | Tool | Components Found | Unknown Licenses | Conflicts | Reviewer |
|---|---|---|---|---|---|---|
Automated results should be reviewed where the license, intended use, or distribution model creates uncertainty.
24. License Compatibility
For applications containing multiple open-source components:
| Application | Component | License | Related Component | Compatibility Issue | Resolution |
|---|---|---|---|---|---|
Status
☐ No known issue
☐ Review required
☐ Potential conflict
☐ Legal review
☐ Remediation required
25. AI and Machine Learning Components
Where applicable, record open-source AI/ML components.
| OSS ID | Model/Framework | Version | License | Application | Dataset/Model Rights Reviewed | Security Review |
|---|---|---|---|---|---|---|
Consider:
- Open-source models
- AI frameworks
- Model weights
- Tokenizers
- Datasets
- Evaluation tools
- ML libraries
- AI development packages
License review should consider the actual terms applicable to the model, weights, code, and associated datasets separately where necessary.
26. Container and Image Components
Where containers are used:
| Image ID | Container Image | Version/Tag | Base Image | License | Application | Registry |
|---|---|---|---|---|---|---|
Review:
☐ Base image identified
☐ Components identified
☐ License information available
☐ Vulnerability scan performed
☐ Image source verified
☐ Version controlled
27. License Conflicts
Record identified or suspected conflicts.
| Conflict ID | Application | Component | License | Conflict | Risk | Action | Status |
|---|---|---|---|---|---|---|---|
28. Legal Review
Legal/compliance review may be appropriate for:
☐ Custom licenses
☐ Unclear licenses
☐ Strong copyleft
☐ License conflicts
☐ Customer distribution
☐ Modified components
☐ Commercial distribution
☐ Source-code obligations
☐ Customer contractual concerns
☐ Significant business exposure
| OSS ID | Legal Review Required | Reviewer | Date | Result |
|---|---|---|---|---|
29. Customer Impact
Identify components that could affect customer contracts or product commitments.
| OSS ID | Customer/Product | Contract Impact | Security Impact | License Impact | Review Status |
|---|---|---|---|---|---|
30. Open-Source Risk Assessment
| OSS ID | Risk | Likelihood | Impact | Risk Rating | Treatment | Owner |
|---|---|---|---|---|---|---|
Potential risks include:
- License conflict
- Unknown license
- Security vulnerability
- Unsupported component
- Supply-chain compromise
- Dependency confusion
- Malicious package
- Customer contractual conflict
- Source-code obligation
- Inability to replace component
- Abandoned project
31. Approval Record
| OSS ID | Decision | Conditions | Approved By | Date | Next Review |
|---|---|---|---|---|---|
Decision
☐ Approved
☐ Approved with Conditions
☐ Further Review Required
☐ Remediation Required
☐ Not Approved
☐ Replace
☐ Retire
32. Exceptions
| Exception ID | OSS ID | Requirement | Reason | Risk | Compensating Control | Approver | Expiry |
|---|---|---|---|---|---|---|---|
Exceptions should be:
- Documented
- Risk assessed
- Approved
- Time limited where practical
- Periodically reviewed
33. Remediation Tracker
| Action ID | OSS ID | Finding | Action | Owner | Due Date | Status |
|---|---|---|---|---|---|---|
Examples:
- Upgrade component
- Replace component
- Remove dependency
- Add license notice
- Update documentation
- Resolve license conflict
- Apply security patch
- Replace unsupported package
34. Change Monitoring
Reassess a component when:
☐ Version changes
☐ License changes
☐ Project ownership changes
☐ Component is forked
☐ Component is modified
☐ Application distribution changes
☐ Customer requirements change
☐ Security vulnerability identified
☐ Project becomes unsupported
☐ Major dependency changes
☐ AI/model usage changes
Change Principle
Change → Assess License → Assess Security → Update Register → Approve
35. Component Retirement
When an open-source component is no longer required:
☐ Removal approved
☐ Application references removed
☐ Dependency removed
☐ Build configuration updated
☐ Container image updated
☐ SBOM updated
☐ Vulnerability monitoring removed
☐ License record updated
☐ Evidence retained
36. Periodic Review
Review the register periodically and when significant changes occur.
Review:
☐ Component inventory
☐ Versions
☐ Licenses
☐ License obligations
☐ Applications
☐ Dependencies
☐ Vulnerabilities
☐ Project maintenance
☐ Distribution model
☐ Customer impact
☐ AI/ML components
☐ SBOM
☐ Exceptions
☐ Open findings
37. Register Summary
| Category | Total | Approved | Review Required | Vulnerable | Unsupported | License Issue |
|---|---|---|---|---|---|---|
| Production Components | ||||||
| Development Components | ||||||
| Runtime Dependencies | ||||||
| Build Dependencies | ||||||
| Container Components | ||||||
| AI/ML Components | ||||||
| Other |
38. License Summary
| License | Component Count | Production Use | Review Required | Known Issues |
|---|---|---|---|---|
This provides management with a high-level view without replacing the detailed component records.
39. Evidence Register
| OSS ID | Evidence Type | Location | Date | Reviewer |
|---|---|---|---|---|
| License file | ||||
| Repository | ||||
| SBOM | ||||
| License scan | ||||
| Security scan | ||||
| Review checklist | ||||
| Approval |
Do not store passwords, API keys, private keys, tokens, or other credentials in the register.
40. AWS SaaS Startup Example
A SaaS startup operates its application on AWS and maintains an application repository.
The application contains several open-source components.
Example Register
| OSS ID | Component | Version | License | Application | Production | Risk | Status |
|---|---|---|---|---|---|---|---|
| OSS-001 | Web Framework | 5.x | SaaS API | Yes | Medium | Approved | |
| OSS-002 | JSON Library | 2.x | SaaS API | Yes | Low | Approved | |
| OSS-003 | Logging Library | 4.x | SaaS API | Yes | Medium | Approved | |
| OSS-004 | Testing Framework | 8.x | Test Suite | No | Low | Approved | |
| OSS-005 | AI Framework | 3.x | AI Service | Yes | High | Review Required |
Example Governance Flow
Developer adds dependency
→ SCA scan identifies component
→ Component added to SBOM
→ License identified
→ Open-Source License Review Checklist completed where required
→ Security vulnerability assessed
→ Customer/distribution impact assessed
→ Approval recorded
→ Open-Source Software Register updated
→ Dependency monitored
41. Startup-Friendly Model
A startup does not need to manually maintain every dependency if automated tooling can provide the detailed inventory.
Use three layers:
Layer 1 — Automated Discovery
Use:
- SCA
- SBOM
- Package managers
- Repository scanning
- Container scanning
Layer 2 — Governance Register
Maintain:
- Component
- Version
- License
- Application
- Owner
- Risk
- Review status
- Approval
- Evidence
Layer 3 — Detailed Review
Perform deeper review for:
- Copyleft components
- Custom licenses
- Modified components
- Customer-distributed software
- Critical production components
- Unknown licenses
- License conflicts
- High-risk AI/ML components
This avoids creating unnecessary manual work while retaining audit evidence.
42. Common Mistakes
Avoid:
- Maintaining only the direct dependencies.
- Ignoring transitive dependencies.
- Recording a component without its version.
- Assuming package name identifies the license.
- Relying exclusively on automated license scanners.
- Ignoring container dependencies.
- Ignoring AI/ML models and datasets.
- Ignoring security vulnerabilities.
- Ignoring abandoned projects.
- Failing to update the register after dependency upgrades.
- Treating open-source software as automatically unrestricted.
- Mixing license compliance with security approval.
- Failing to retain evidence of important license decisions.
43. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Open-Source License Review Checklist | Performs detailed license assessment |
| Software License Register | Maintains broader software licensing inventory |
| Intellectual Property Register | Records IP ownership |
| Open-Source Software Policy | Defines organizational requirements |
| Software License Compliance Procedure | Defines license-management process |
| SBOM | Provides detailed component inventory |
| Vulnerability Management Procedure | Tracks security vulnerabilities |
| Secure Development Policy | Governs software development |
| Change Management Procedure | Controls dependency changes |
| Supplier Security Assessment | Assesses external software providers |
| Customer Contract Security Review | Identifies customer-specific obligations |
| Risk Register | Tracks significant OSS risks |
44. ISO/IEC 27001 Connection
The Open-Source Software Register can support the organization’s risk-based management of:
- Software assets
- Intellectual property
- Secure development
- Technology supply-chain risks
- Vulnerability management
- Change management
- Supplier relationships
- Legal and contractual requirements
- Information-security risks
The Open-Source Software Register is not itself a universally mandatory ISO/IEC 27001 document.
The organization should determine the appropriate level of inventory and review based on:
- Risk
- Software development model
- Product architecture
- Customer commitments
- Legal/licensing requirements
- Security requirements
- Technology supply-chain exposure
The relevant controls should be addressed through the organization’s risk assessment and applicable Statement of Applicability.
45. Audit Evidence
Examples of evidence include:
- Open-Source Software Register
- SBOM
- Dependency manifests
- Package-lock files
- SCA reports
- License scan reports
- LICENSE files
- Repository records
- Version records
- Vulnerability reports
- Security scan results
- Open-Source License Review Checklists
- Approval records
- Legal reviews
- Exception records
- Remediation records
- Software change records
- Retirement records
46. Final Audit Trail
For each significant open-source component, the organization should be able to demonstrate:
What component are we using?
Which exact version are we using?
Where did it come from?
Which application uses it?
Is it direct or transitive?
What license applies?
Has the license been reviewed?
What obligations apply?
Are we modifying or distributing it?
Are there security vulnerabilities?
Is the project maintained?
What customer or contractual impact exists?
Who approved its use?
What evidence supports the decision?
When will it be reviewed again?
47. Final Principle
Discover → Identify → Version → Verify License → Map to Application → Assess Security → Assess Obligations → Approve → Record → Monitor → Update → Retire
The Open-Source Software Register should be a living governance record, not simply a spreadsheet created for an audit.
The strongest approach is to connect SCA/SBOM discovery → license review → security assessment → risk decision → approval → ongoing monitoring so that the organization can demonstrate exactly what open-source software it uses and why its continued use is acceptable.