Reading an SDLC from its artefacts, and why it fails without estate controls

Most software disputes eventually turn on a simple question: did the team build the software the way it said it would? Suppliers describe their software development lifecycle (SDLC) in proposals, security questionnaires and statements of work. Code review, automated testing, segregated environments, controlled releases. The question for an expert is whether the artefacts left behind by the work support that description.

They usually can, because modern development generates a detailed trail as a side effect. But there is a second question that gets asked far less often, and it matters just as much: was the IT estate the team worked on controlled well enough for that trail, and the software itself, to be trusted?

What the artefacts show

A well-run SDLC leaves evidence in several independent systems. Where they agree with each other, the picture is strong. Where they do not, the inconsistencies are usually where the dispute is.

• Branch protection and repository settings. Whether the main branch required pull requests, a minimum number of approvals, passing status checks and signed commits, and whether administrators could bypass those rules. Hosting platforms record changes to these settings in their audit logs, so it is possible to show whether protection was in place on a given date, or switched off before a release.
• Pull request records. Who opened each change, who approved it, how long review took and what was said. Approval patterns are revealing: a single reviewer approving every change, approvals within seconds, or authors approving their own work through a second account.
• CI/CD run history. Every pipeline run, the commit it built, which tests and scans ran, and whether failures were overridden. A pipeline that has been red for weeks while releases continued tells you the tests were not a gate.
• Test results over time. Not just the coverage figure, but whether tests were added alongside features, and whether failing tests were fixed, skipped or deleted.
• Release tags against deployment logs. Whether what was deployed to production was the tagged, tested build, or something built on a developer’s machine and copied up.
• Ticket-to-commit traceability. Whether each change links to a requirement or defect, so that work can be traced from what was asked for to what was shipped.

Taken together, these show whether the documented process was the real process. Taken individually, each can be incomplete or misleading, which is why I always reconcile them against each other rather than relying on one.

Why estate controls matter

All of the above assumes that the machines and accounts producing those records were controlled. If they were not, two things go wrong at once: the software can be compromised in ways the SDLC never sees, and the evidence of how it was built becomes much weaker.

The baseline controls I would expect for any team building software for clients are not exotic:

• Managed devices. Developer laptops enrolled in a device management platform (such as Microsoft Intune or a comparable MDM), with enforced disk encryption, patching, screen lock, and the ability to wipe a lost or departing device.
• Identity controls. Single sign-on to source control and cloud platforms, multi-factor authentication, conditional access that only allows compliant devices to reach the repository, and prompt removal of leavers.
• Endpoint protection. Endpoint detection and response (EDR) on every machine that holds source code or credentials, with alerts that someone actually reviews.
• Data loss prevention. Rules covering source code, secrets and client data: blocking uploads to personal storage and unapproved AI tools, controlling removable media, and monitoring for bulk cloning or downloads.
• Secrets management. Credentials held in a vault and injected at runtime, not stored in repositories, environment files on laptops or chat messages.

How the SDLC fails without them

When these controls are missing, the failures follow familiar patterns.

The code leaves with the people. On unmanaged devices, there is no way to stop a departing developer keeping a full clone of the repository, or to show afterwards that they did not. In disputes over misuse of source code or confidential information, the absence of DLP and device logs often means the most important question, what was taken, cannot be answered either way.

Builds happen outside the pipeline. If developers can deploy from their own machines, the release record no longer shows what is running in production. I have seen production systems running code that never appeared in the repository at all, because a hotfix was built and uploaded from a laptop and never committed.

A compromised laptop compromises the product. Without EDR, a developer machine infected with credential-stealing malware gives an attacker the same access to the repository, the pipeline and the cloud accounts as the developer. Code review does not protect against someone pushing with stolen, valid credentials, and branch protection does not help if the stolen token belongs to an administrator.

Secrets end up everywhere. Without managed devices and secret scanning, API keys and database passwords spread into local files, shell history, screenshots and personal backups. When a breach happens, the organisation cannot establish which copy leaked.

The audit trail is incomplete. Device, identity and endpoint logs are what tie an action in the repository to a person on a particular machine at a particular time. Without them, a commit under a developer’s name shows only that their credentials were used. That is a significant weakness when authorship or responsibility is disputed.

What this means in a dispute

When I assess whether a supplier followed a competent SDLC, I look at the development artefacts first, because they show the process. Then I ask what sat underneath them: which devices could reach the code, how identity was controlled, whether endpoints were monitored, and whether data leaving the estate was controlled. An organisation that claims ISO 27001 or Cyber Essentials, or answered “yes” to these controls in a security questionnaire, should be able to produce the configuration and logs to match.

A tidy Git history built on an uncontrolled estate is a good story with weak foundations. The strongest position, for a supplier defending its work or a customer challenging it, is one where the development records and the estate records agree.