67 lines
2.7 KiB
Markdown
67 lines
2.7 KiB
Markdown
Title: Secure Code Review Standard
|
|
Document ID: [STD-CODEREVIEW-001]
|
|
Version: 0.1 Draft
|
|
Status: Draft
|
|
Owner: CISO (Paul Jenkins)
|
|
Approver: CISO (Paul Jenkins)
|
|
Classification: Internal
|
|
Effective date: [DD Month YYYY]
|
|
Review date: [DD Month YYYY]
|
|
|
|
# Secure Code Review Standard
|
|
|
|
## Purpose
|
|
|
|
This standard defines the minimum requirements for reviewing code and related changes for security impact before promotion to production use.
|
|
|
|
## Scope
|
|
|
|
This standard applies to application code, infrastructure as code, deployment manifests, pipeline definitions, configuration changes, and related engineering artefacts within the ISMS scope.
|
|
|
|
## Mandatory Requirements
|
|
|
|
Changes must be reviewed before merge or release using a process appropriate to the risk and criticality of the change.
|
|
|
|
Reviewers must assess whether the change introduces material security impact, especially where authentication, authorisation, data handling, cryptography, logging, infrastructure control, or externally exposed services are affected.
|
|
|
|
High-risk changes must receive review by personnel with appropriate security or domain competence.
|
|
|
|
Code review records must provide sufficient traceability to show what was reviewed, by whom, and with what outcome.
|
|
|
|
Automated checks may support code review but must not be treated as a complete replacement for human assessment where security judgement is required.
|
|
|
|
Emergency changes must be reviewed retrospectively where pre-implementation review is not feasible.
|
|
|
|
## Implementation Guidance
|
|
|
|
BlackDice should align review depth with change risk so that routine low-risk changes remain efficient while high-impact changes receive greater scrutiny.
|
|
|
|
Review expectations should cover not only application source code but also infrastructure and deployment changes that can materially affect service security.
|
|
|
|
Where specialised security review is not immediately available, compensating approval or targeted post-change review should be defined.
|
|
|
|
Patterns of repeated review findings should inform secure development guidance, training, and pipeline checks.
|
|
|
|
## Roles and Responsibilities
|
|
|
|
- [Role] must define secure code review expectations.
|
|
- Developers and change authors must submit changes for review with enough context to support assessment.
|
|
- Reviewers must assess security-relevant impact before approval.
|
|
|
|
## Exceptions
|
|
|
|
Exceptions must be documented, justified, risk-assessed, approved, and reviewed.
|
|
|
|
## Related Documents
|
|
|
|
- Secure Development Policy
|
|
- CI/CD Security Standard
|
|
- Change Management Policy
|
|
- Production Deployment Procedure
|
|
|
|
## Version Control
|
|
|
|
| Version | Date | Description of Change | Author |
|
|
| --- | --- | --- | --- |
|
|
| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |
|