Bot-authored changes: what the auditor reads in them
Dependency updates, generated configuration and scheduled housekeeping are often opened by a bot account. The change still has to be approved by a person who is not the bot. The checker marks the author as automated and lists the change when no such person approved it.
How the checker recognises them
Read from the author name: a bracketed bot suffix, a name ending in bot, a service account prefix, or a pipeline or automation account.
Findings they raise most often
- Automated author, no human approval: Which person reviewed and approved this change written by an automated account, and were they independent of whoever started the job?
- No independent approval: Who approved this change before it reached production, and where is that approval recorded by someone other than the author?
The clauses that speak to them
3 clausesCOBIT BAI06.01 Evaluate, prioritize and authorize change requestsThe clause text
All requests for change are evaluated to determine their impact on business processes and I&T services and to assess whether the change will adversely affect the operational environment and introduce unacceptable risk, and changes are logged, prioritised, categorised, assessed, authorised, planned and scheduled: formal change requests let process owners and IT request changes to processes, infrastructure, systems or applications, with all changes arising only through the change management process and pre-screened for standard changes; requests are categorised (business process, infrastructure, operating systems, networks, applications, packaged software) and related to affected configuration items; they are prioritised on business and technical requirements, resources and legal, regulatory and contractual reasons; each change is formally approved by process owners, service managers and IT technical stakeholders as appropriate, with low-risk frequent changes pre-approved as standard; approved changes are planned and scheduled; every request is evaluated in a structured way with impact analysis on processes, infrastructure, systems, applications, continuity plans and service providers so that all affected components are identified; and the effect of contracted providers on change management is considered, including integration of their processes into the enterprise's.
Where it usually falls short: Changes made outside the process by administrators with direct access; Impact analysis that ignores the continuity plan and outsourced components
Source: COBIT 2019
ISO 27001 8.25 Secure development life cycleThe clause text
Establish and apply rules for secure development of software and systems.
Where it usually falls short: Policy exists but not enforced; Threat models not updated for new features
Source: ISO/IEC 27001:2022
SP 800-53 SA-10 Developer configuration managementThe clause text
Requires the developer of the system, component or service to perform configuration management during defined life cycle stages, to document and control the integrity of changes to defined configuration items, to implement only organization-approved changes, to document approved changes with their potential security and privacy impacts, and to track security flaws and their resolution and report findings to defined personnel.
Where it usually falls short: Obligations assumed from the developer's own process with nothing in the contract; No visibility of developer changes, so approval is nominal
Source: NIST SP 800-53 Rev 5