A dependency update changes more than a version number
Review the resolved code, its build-time access and the path to production. A clean vulnerability scan is useful evidence, not a complete trust decision.
Read articleAI implementation, software architecture, cloud operations and Australian technology policy.
40 articles in Security and operations
Page 1 of 3
Review the resolved code, its build-time access and the path to production. A clean vulnerability scan is useful evidence, not a complete trust decision.
Read articleGive each workload the authority required for its job and no unrelated administration path. Separate who may assume the identity from what that identity may do.
Read articleAn incident handover should explain impact, active changes and the next decision. Preserve the timeline as evidence, but do not make a tired responder reconstruct it from hundreds of messages.
Read articleRetention needs a map of data destinations, an approved policy and evidence from each removal path. Backups and derived indexes require explicit treatment.
Read articleCapture resolved packages and execution changes before building the release. Keep exceptions and artifact evidence connected to the same review.
Read articleTurn application behaviour into specific allowed actions, then test the identity that will actually run the service.
Read articleKeep the current operating picture easy to find while preserving how it changed. Link actions to owners and evidence rather than burying them in narrative updates.
Read articleSeparate eligibility from execution and track each copy. A resumable workflow makes partial deletion visible instead of hiding it behind one database status.
Read articleFocus on the behaviour and privileges introduced by an update. Installation, malformed inputs and fallback code can matter more than the happy-path API call.
Read articlePositive tests establish functionality. Deliberate denial tests establish the boundaries that make a service identity useful.
Read articleA rehearsal reveals missing context quickly. Give the incoming responder only the record and ask them to explain the next safe action.
Read articleRetention testing must include partial failures and recovery. A record disappearing from the live screen is only the first observation.
Read articleAlert totals need context about execution, reachability and ownership. A smaller number can reflect better risk treatment or merely broader suppression.
Read articlePermission quality depends on purpose, effective reach and tested boundaries. A policy can avoid an asterisk and still grant the wrong service too much authority.
Read articleHandover quality appears in continuity of decisions, not document length. Track missing state, repeated experiments and unowned follow-up work.
Read articleA job-success counter can hide failed destinations and overdue records. Track complete outcomes, authorised holds and unresolved copies separately.
Read articleA dependency incident starts with exposure mapping. Determine where the code ran and which credentials or data were available before choosing the recovery action.
Read articleIdentify the actual principal, action and target. A narrow correction is possible only after the failed operation is understood.
Read article