016 | The software patch

“The small repair that became a permanent way of life”

The defect has been found.

The whole system cannot conveniently be rebuilt.

So we alter the smallest possible part and hope the patient survives the treatment.

Today a patch may be a digitally signed package downloaded to millions of machines, tested against fleets of devices, scheduled through change windows and recorded in vulnerability-management dashboards whose traffic-light colours provide executives with the reassuring sensation that causality has been domesticated.

The first software patches were rather more literal.

They involved paper, scissors, glue, adhesive tape and a small brass instrument called a bodger.

The outline for this series calls the patch “a superbly literal term”: early programs stored on paper tape or punched cards could be corrected by covering, replacing or splicing the defective section. The name survived long after the paper disappeared, while cybersecurity turned patching into a recurring ceremony of discovery, repair, testing, deployment and reluctant compliance.

That modest piece of repaired tape deserves its place in cybersecurity history because it introduced one of the field’s most consequential ideas:

A deployed system does not become secure by being finished.
It becomes secure by remaining changeable.

The hole that should not have been there

Programs for some of the earliest computers were stored on punched paper tape.

Each position across the tape represented a binary value. A punched hole meant one thing; an unpunched position meant another. The tape passed through a reader, and the pattern of holes became instructions.

This created a rather physical debugging problem.

If a required hole was missing, another hole could be punched.

If a hole had been punched where none should exist, the programmer could not unpunch it. Reality had already committed the change.

The error had to be covered and the correct pattern punched again.

Surviving Harvard Mark I programme tape shows small pieces placed over incorrect sections and repunched. Harvard’s historical collection explicitly describes these as patches, alongside other programming terms that originated in the physical behaviour of the machine and its paper media.¹

The metaphor was almost embarrassingly exact.

A damaged garment was patched with cloth.

A leaking roof was patched with whatever prevented the weather entering.

A defective program was patched with another piece of paper.

The repair did not replace the whole object. It covered or substituted the local failure.

That is still what we mean.

Joan Travis and the bodger

One of the most evocative surviving patching kits belonged to Joan Travis, née Kaye, a programmer at Ferranti in Manchester.

In 1953, Travis joined the programming team working with the Ferranti Mark 1 and Mark 1*, descendants of the Manchester Baby and among the earliest commercially available stored-program computers.

Incredibly, although officially indexed in the permanent archives under Object Number co8985543 by the Science Museum Group Collection³, there is no photograph available. Whilst some of Turing’s writings remaining classified is understandable – for the protection of what we often describe as “Capabilities and Methods”, because he was that far ahead with his thinking, it seems extraordinary that such a fascinating object as this should remain concealed from view.

The Science Museum records another detail that should not be allowed to pass quietly:

When Travis joined Ferranti in April 1953, eight of the fourteen programmers were women.

Not assistants to the programmers.

Not typists transcribing instructions conceived elsewhere.

Programmers.

The programs they worked upon included calculations for aircraft design, atomic-weapons research and industrial work for Shell. These were not decorative demonstrations arranged so that visitors could watch an electronic machine produce a reassuring sequence of numbers. They were serious applications running on some of the most advanced equipment then available.

Travis herself had studied mathematics, physics and chemistry, entered Ferranti’s programming group in 1953 and continued working with computers and software for decades. Her career eventually stretched from the Ferranti Mark 1 to an era in which laptops and mobile telephones were beginning to appear.⁴

Yet the ordinary history of the software patch rarely mentions her.

It prefers the abstract progression: paper tape became magnetic tape; magnetic tape became disks; disks became downloads; downloads became automatic updates.

The hands disappear. The woman holding the scissors disappears.

The maintenance work becomes a mechanism rather than an activity performed by someone who had to understand the programme well enough to change it without destroying everything around it.

But Joan Travis’s bodger is as legitimate a cybersecurity artefact as any famous cipher machine.

It embodies the first necessary security property of a patch:

precision.

Punch the wrong position and the repair becomes another defect.

Software that could be touched

Early software was materially visible.

A programme might be a roll of tape, a tray of cards or a carefully ordered deck whose sequence mattered as much as the individual instructions. It could be dropped, torn, misordered, duplicated, annotated or repaired.

The programme had edges.

A patch changed some of those edges without recreating the whole artefact.

This physicality shaped early programming language. Harvard’s Mark I history also records that sections of paper tape could be cut out, stored and later joined together to create a “library” of reusable code. A loop was quite literally a loop of tape.⁵

We now use these words while manipulating abstractions.

The loop has no visible circular form.

The library is not stored in a cabinet.

The patch is no longer adhesive.

But the language remembers the material world from which programming emerged.

That memory matters because it reveals what a patch fundamentally is.

It is not “the new software”.

It is a description of the difference between what exists and what should exist.

The first maintenance problem

The first programmers did not merely write programs.

They operated machines, diagnosed failures, prepared media, changed instructions, reran calculations and preserved routines that might be useful later.

There was rarely a clean organisational separation between development, operations and maintenance. The person who wrote the code might also load it, watch the machine execute it, recognise from the sound that something had gone wrong and then alter the physical programme.

This was less a DevOps revolution than the absence of enough humans to create departmental borders.

Once computers were installed in multiple organisations, however, maintenance became a distribution problem.

A defect might be discovered at one site.

Other installations might possess the same programme.

Each site might already have made local changes.

A vendor could supply a corrected routine, but applying it might overwrite local modifications or depend upon earlier corrections.

Software had acquired versions and branches.

Versions had acquired ancestry.

And ancestry, as we have already learned from Enigma, becomes dangerously important when institutions stop recording it.

Customers invent software support

In the early 1950s, computer manufacturers often supplied hardware, documentation and a less than exhaustive quantity of help.

Customers therefore shared routines, operating techniques and corrections with one another.

In August 1955, representatives of seventeen organisations that had ordered IBM 704 computers met at the RAND Corporation and formed SHARE, one of the earliest computer user groups. The name described its purpose: members exchanged information and programmes between installations. Its first substantial product was a software reference manual for the IBM 704.⁶

This was not yet open-source development in the modern sense, but the family resemblance is clear.

Users had similar machines.

They encountered similar problems.

The manufacturer had not supplied every required answer.

So they exchanged code.

In the 1950s, software was often bundled with hardware or freely shared among users rather than sold as a separate commercial product. IBM accumulated a large software library, and SHARE members traded programs and documentation that IBM itself did not provide. IBM’s 1969 decision to unbundle much of its software helped transform programs into separately valued commercial products, but the culture of users exchanging fixes had already existed for years.⁷

The patch therefore grew from two related instincts:

Firstly, repair the programme without replacing all of it;

Secondly, share the repair so everyone else does not have to rediscover the same defect.

Human civilisation has occasionally managed this principle outside computing, although generally only after forming a committee to investigate whether knowledge sharing can be monetised, and whether it might create reputational risk.

The local fix

Shared software produced another familiar phenomenon.

The local modification.

An organisation received a standard programme, altered it to meet local requirements and then discovered that the next official release assumed the original version was still present.

The vendor’s fix “corrected” the vendor’s programme.

The customer no longer possessed precisely that programme.

Applying the change could fail, overwrite local behaviour or produce a hybrid system understood only by the person who retired three reorganisations ago.

The modern “snowflake server” was not invented by virtualisation, cloud computing or an administrator named Dave.

It was present almost as soon as software travelled between sites.

This is where patching became more than editing.

It became configuration management.

To patch safely, an organisation needed to know:

• which version was installed;
• which local changes had been made;
• which earlier fixes were already present;
• what the new repair expected to find;
• what depended upon the component being changed;
• and how to restore the previous state if confidence turned out to have been misplace.

The patch had created the need for provenance.

IBM gives temporary fixes permanence

Large mainframe environments formalised software maintenance into controlled processes.

IBM developed a vocabulary that survives within its systems:

An APAR, or Authorized Program Analysis Report, records a suspected or confirmed defect and its analysis.

A PTF, or Program Temporary Fix, provides the corresponding correction.

A PTF may replace or update one or more software elements, relink modules and depend upon prerequisite PTFs being present. IBM systems distinguish between applying a change in a reversible way and committing it so that ordinary removal is no longer available. (IBM)

The terminology contains one of computing’s finest bureaucratic jokes.

A Program Temporary Fix may become the permanent and official correction for that software release.

IBM’s own glossary explains that where no later release incorporates the correction, the PTF is not temporary at all but becomes the permanent correction mechanism.⁸

Temporary, in this context, means permanent until replaced by a different form of permanence.

Civilisation continues to operate on similar principles.

There is also the PTF in Error, abbreviated PE: a fix subsequently found to contain its own defect. IBM maintenance systems track not only the correction, but corrections to corrections and the dependencies needed to avoid installing a known-bad repair.

This is not an embarrassing edge case.

It is one of the central truths of patching.

The patch is software.

Software can contain defects.

Therefore the mechanism intended to remove risk can create new risk.

Recursion has entered the change window, and asks you to hold its beer.

The patch changes shape

As programs moved from paper tape and cards to magnetic media and disks, the patch ceased to be a physical object attached to the original programme.

It became a set of replacement instructions.

A vendor might distribute altered modules, binary changes or a maintenance tape. The customer installed those changes against an existing software level.

The underlying idea remained the same:

Do not send the entire system again.

Send what must change.

This reduced distribution costs and installation time, but it introduced a demanding requirement.

The recipient had to possess the expected starting state.

A patch describing the difference between versions A and B may not apply correctly to version A-with-three-local-changes-and-an-unrecorded-hotfix.

The patch is meaningful only in relation to a baseline.

This is why change management eventually becomes a history problem.

You cannot reliably transform the present unless you know which past produced it.

diff and the portable difference

Unix culture gave the patch a new and immensely influential form.

The diff utility compared files and described the lines that differed. At first, such output was primarily something a human could read. It showed what had changed, but applying those changes elsewhere remained a manual task.

Larry Wall’s patch program turned a diff into something another machine could apply.

Wall began developing the tool in 1984, and version 1.3 was distributed through the mod.sources Usenet group in 1985. Its revision history records the pleasing fact that the program created to apply patches was itself repeatedly patched for memory errors, portability problems, reversed diffs and other defects.⁹

That was a profound change in software collaboration.

A developer no longer needed to send a complete modified source tree.

They could send the difference.

The receiver could inspect it, apply it, reverse it or discover that part of it no longer matched because the target had changed. GNU’s documentation still describes the process in essentially those terms: generate differences between releases and feed the resulting patch to the patch program to update the older source. (GNU)

The patch had become a portable changeset.

Small enough for electronic mail.

Readable by humans.

Actionable by machines.

And capable of failing halfway through because reality did not precisely resemble the author’s copy.

A perfect ancestor of modern deployment.

A patch is not a programme

This distinction is important.

A patch may contain code, but its meaning comes from the relationship between two states.

Imagine the instruction:

Replace line 40 with this corrected version.

That instruction assumes:

• the file exists;
• it is the expected file;
• line 40 contains the expected old text;
• earlier changes have not moved or altered the relevant section;
• the replacement is valid in the surrounding context.

Modern patch formats include context to help locate the intended change even when line numbers have moved. If the surrounding text differs too much, the change may be rejected rather than applied to the wrong location.

This is a primitive but important safety property.

The patch tool does not merely ask:

Can I write these bytes?

It asks:

Does this still appear to be the place the author intended to change?

Intent is being inferred from context.

Anyone who has reviewed a modern pull request has inherited this idea, whether they realise it or not.

From defect to vulnerability

Early patches primarily corrected faults.

The programme returned the wrong answer.

The device behaved unpredictably.

A feature failed under some input.

The distinction between ordinary defect and security vulnerability was less prominent because most computers were isolated, expensive and used by small groups of authorised people.

As systems became shared and networked, the consequences changed.

A flaw was no longer only something that might inconvenience the legitimate user.

It might be something another person could deliberately trigger.

The bug became an entry point.

And the interval between discovering the vulnerability and installing the patch became an exposure window.

That turned patching from software maintenance into cybersecurity.

The worm and the frantic cure

On 2 November 1988, the Morris worm spread across the early Internet. I wrote an account of this incident in 1990/1991; you won’t find it because it exists only as a single physical bound copy on my bookshelf. I mention it merely because it shows how significant I found it to be at the time.

It exploited, among other things, a buffer overflow in the fingerd service and a dangerous debugging facility in sendmail. It also abused trust relationships and weak passwords to move between systems. Plus ça change!

The response was strikingly… improvised.

Researchers and administrators analysed the worm, telephoned one another, exchanged electronic mail and distributed information describing how to remove or disable the vulnerable behaviour. Sites patched the sendmail debug command, fixed or disabled fingerd and took other emergency measures.

Once the holes had been closed, the worm could no longer reinfect those systems through the same paths. Most affected computers were cleared within roughly 48 to 72 hours, largely through work performed by university computing staff.¹⁰

This was patch management before patch-management infrastructure.

No global update service.

No asset dashboard.

No standard vulnerability identifier.

No vendor portal.

No automated compliance report assuring management that 96.4 per cent of endpoints had entered a state adjacent to safety.

There were people, source code, telephones, electronic mail and urgency.

Interestingly, as I noted in my write-up at the time, those institutions that isolated themselves from the network thinking that this would help actually suffered the most. They cut themselves off from the sources of information about remediation development and application.

The incident exposed a coordination failure as much as a software failure. In its aftermath, DARPA asked Carnegie Mellon’s Software Engineering Institute to establish what became the CERT Coordination Center, creating a durable mechanism for coordinating incident information, vulnerabilities and fixes.¹¹

The patch had become an emergency public-health measure for networks.

Find the infection route.

Distribute the remedy.

Reach enough systems before propagation outruns repair.

The patch gap

A patch does not protect a system when it is written.

It protects the system when it is correctly installed. It protects the wider “systems across the Internet” when it is sufficiently widely installed – like the herd immunity principle for vaccination.

Between those events lies the patch gap.

During that interval:

• the vendor may know the vulnerability;
• researchers may know it;
• customers may know that a fix exists;
• attackers may be studying the fix to determine what it reveals;
• and the vulnerable system continues running because the next approved maintenance window is three Thursdays away.

Publishing a patch may therefore help defenders and attackers simultaneously.

The fix tells defenders how to close the weakness.

The difference between old and new code may tell attackers where the weakness was.

This does not mean patches should be withheld.

It means disclosure, distribution and deployment are one connected security process.

A patch sitting in a catalogue is not remediation.

It is an opportunity to remediate.

Those are not the same thing, however attractively the ticket has been categorised and marked as “Urgent!”

Why administrators hesitate

It is tempting to describe unpatched systems as evidence that administrators are lazy, users are foolish, and organisations have failed to absorb a sufficiently colourful awareness poster.

Sometimes this is even true.

But patching contains real risk.

A patch may:

• break compatibility;
• alter performance;
• require downtime;
• depend upon another patch;
• invalidate a certification;
• conflict with local modifications;
• fail during installation;
• reveal that the documented recovery procedure was essentially speculative fiction;
• or repair one vulnerability while introducing another.

Critical systems may be difficult to test realistically. Medical equipment, industrial controllers, policing systems, aircraft, laboratory instruments and operational technology cannot always be rebooted whenever a vendor develops enthusiasm.

The choice is therefore not:

safe patching versus reckless inaction.

It is often:

the risk of changing the system versus the risk of leaving the system unchanged.

This returns us to the lesson already visible in the one-time pad.

Security is a balance between competing risks, costs and inconveniences.

Not patching is still a change decision.

It preserves the current vulnerability.

Apply, test, verify

Modern patch management is not merely installation.

NIST defines enterprise patch management as identifying, prioritising, acquiring, installing and verifying patches, updates and upgrades across an organisation. It frames the work as preventive maintenance and a necessary cost of operating technology rather than an optional technical improvement.¹²

Each verb matters.

Identify: What systems and versions exist?

Prioritise: Which defects create the greatest actual risk?

Acquire: Has the patch come from an authentic source?

Install: Can it be deployed safely and consistently?

Verify: Did it take effect, or did the installer merely produce a reassuring message?

The last step is frequently neglected.

A management platform may report that an update command was sent.

That is not the same as confirming that the corrected component is both installed correctly and that it is actually running.

Security has many mechanisms for confusing attempted action with achieved outcome. Project reporting has built an entire economic sector around the distinction.

The update channel becomes part of the attack surface

When patches were applied with scissors, the attacker had to interfere with the physical tape or persuade the programmer to make the wrong change.

When patches are distributed automatically across the Internet, the update mechanism becomes extraordinarily powerful.

It has permission to replace trusted code.

It may run with the highest system privileges.

It may reach thousands or millions of devices.

It may be accepted because the recipient has been taught, correctly, that updates are essential.

The patching system is therefore both a defence and a supply chain.

Modern update security requires:

• authenticated sources;
• cryptographic signatures;
• protected signing keys;
• integrity checks;
• controlled deployment;
• rollback mechanisms;
• audit records;
• and confidence that the vendor’s build and distribution infrastructure has not itself been compromised.

A malicious update delivered through a trusted channel is not defeated by better user awareness.

The user is doing precisely what security guidance instructed them to do.

Trust has been attacked upstream.

The patch is no longer merely repairing the attack surface.

It is part of it.

Automatic updates and the surrender of choice

Manual patching does not scale well.

Users forget.

Administrators delay.

Devices remain offline during the approved period.

Applications depend upon versions nobody realised were still in use.

The logical response was automation.

Systems began checking for updates, downloading them, scheduling installation and eventually applying them with decreasing interest in whether the person using the machine had arranged their afternoon around a forced restart.

This reduced widespread exposure.

It also transferred control.

The vendor could now change software already deployed in homes, businesses and public infrastructure. The user gained faster repair but lost some ability to defer, inspect or reject changes.

Again, cybersecurity exchanges one risk for another.

Manual control creates delay and inconsistency.

Automatic control creates dependency upon the update provider and its security.

Neither is intrinsically perfect.

Perfection remains unavailable, despite several subscription tiers suggesting otherwise.

The invisible maintainers

Software history celebrates creation.

The first programme.

The first compiler.

The first operating system.

The breakthrough algorithm.

The architect who conceived the system.

Maintenance rarely receives similar treatment.

The person who spends ten years finding defects, preserving compatibility, reviewing patches, backporting security fixes and preventing regressions is described as maintaining someone else’s achievement.

Yet software that is not maintained becomes unusable, unsafe or both.

The original programmer may create the system.

Maintainers keep it in civilisation.

This work is unusually difficult because it operates under constraint. The maintainer must improve the software without breaking existing behaviour relied upon by people who may never have documented what they were doing.

They must understand:

• the original intent;
• the current implementation;
• accumulated local expectations;
• the newly discovered defect;
• and the consequences of altering it.

Writing a new system permits design freedom.

Patching an old one requires archaeology, caution, and quite possibly OCD tendencies.

Risk Appetite – modern approach

To cope with the rapidly reducing gap between zero-day discovery and zero-day exploitation we need to patch quicker.

But patching involves risk: risk to the availability of the system.

Over the last year or so I have had to undertake several discussions about Risk Appetite with Risk Owners – those individuals specifically (and legally) accountable for, and answerable about, risk decisions.

The discussion inevitably goes like this:

I say “You need to accept a greater probability of update/patching causing system availability impact”

They say “But why?!”

I say “Because if you don’t then you are implicitly accepting a greater risk of data exposure through successful exploitation of vulnerabilities. If you accept a greater risk to availability then we can minimise the risks to confidentiality. But this is your choice to make”

They say “I see your point. Patch as quickly as you can. What happens if a patch breaks something?”

I say “Then we roll it back and work out what to do next. But most of the time that will not happen”

They say “JFDI” (or equivalent).

Real risk management involves balancing risks.

The women beneath the maintenance story

The physical history of patching also exposes another disappearance.

Punched-card and paper-tape preparation was frequently treated as clerical work, and keypunch operation became heavily associated with women. The Computer History Museum notes that punching cards was categorised as secretarial or clerical labour and therefore regarded, in the language of the period, as women’s work.¹³

But creating, checking and repairing programme media could demand detailed technical knowledge.

At Ferranti, Joan Travis and the other women in the programming team were not merely producing media for male analysts. They were writing, diagnosing and altering programs.

The tools survived.

Some of the tape survived.

The names did not travel so well.

This pattern should now be familiar.

Technical prestige attaches to the moment of invention.

Routine responsibility attaches to the people who make the invention function repeatedly.

When that routine work is performed by women, assistants, operators, support staff or junior personnel, history has an alarming tendency to treat it as environmental background.

The machine worked.

The programme ran.

The tape somehow acquired the correct holes.

Apparently the bodgers emerged at night and operated themselves, one might be left thinking.

The patch that becomes architecture

A patch is supposed to be local.

Small.

Temporary.

An exception until the underlying product is repaired properly.

But patches accumulate.

A product may contain years of corrections layered over its original design. Some fixes alter behaviour upon which later fixes depend. Some compatibility workarounds must remain because an external system relies upon the mistake.

Eventually the patched system is not the original system plus a few repairs.

It is the original system plus its history.

Removing the apparently obsolete workaround may expose that another component has depended upon it since 1997.

This is why mature software can seem irrational.

It is not always badly designed in the present.

It is carrying treaties negotiated with every past environment it has survived.

The code contains fossils.

The permanent emergency

A security patch often arrives under urgency.

Deploy immediately.

Exploit observed.

Critical severity.

No user interaction required.

Remote code execution.

The language is justified, but an organisation cannot operate indefinitely as though every change were an unprecedented emergency.

Emergency patching must itself be a designed capability.

There must be:

• an accurate inventory;
• established authority to act;
• test environments;
• deployment tooling;
• prioritisation criteria;
• fallback plans;
• communication routes;
• and people available who understand the affected systems.

Otherwise every urgent patch becomes an improvised negotiation among security, operations, suppliers, service owners and the individual who knows the password for the machine in the locked cupboard.

The patch is small.

The capability to deploy it safely is not. Governance matters.

The artefact is not the fix

The artefact for this article could be the patched Harvard tape.

It could be Joan Travis’s brass bodger.

It could be an IBM PTF tape.

It could be Larry Wall’s patch source distributed through Usenet.

But the real artefact is the difference.

The recorded statement that one state is defective and another is preferred.

That difference must be: understood; transported; trusted; applied; verified; and preserved as part of the system’s history.

The patch is not simply code.

It is a controlled transition.

That is why it belongs in cybersecurity rather than merely software engineering.

Security depends upon the ability to change deployed systems faster than adversaries can exploit what is wrong with them, but slowly and carefully enough that the cure does not become the next incident.

A ridiculous requirement.

Also the job.

The lesson at the end of the octet

This octet began with electrical machines encrypting communication.

It passed through perfect secrecy, intercepted diplomacy, Enigma, rumrunners, spies, invisible women, Polish mathematics, perforated sheets and ranks of rotating Bombe drums.

It ends with a piece of adhesive tape.

That is appropriate.

Cybersecurity is often described through great systems and dramatic attacks, but much of it consists of small corrections performed by people whose names will never be attached to the product.

A hole covered.

An instruction replaced.

A dangerous option disabled.

A bounds check added.

A dependency updated.

A vulnerable service restarted.

One small change preventing one large consequence.

The first patch was a physical repair to a programme that could be held in the hand.

The modern patch may cross the world in seconds and alter millions of machines.

The material changed.

The obligation did not.

No software is perfect.
No release is final.
No security architecture survives indefinitely without maintenance.

Security is not the absence of mistakes.

It is the capacity to discover them, admit them, repair them and survive the repair.

Because a system that cannot be changed when it is wrong is not secure.

It is merely waiting to fail permanently.

References & Links

1. https://chsi.harvard.edu/harvard-ibm-mark-1-language ↩︎
2. https://collection.sciencemuseumgroup.org.uk/objects/co9015990/manual-paper-tape-editing-equipment-for-programming-the-ferranti-mark-1-and-mark-1-computers ↩︎
3. https://collection.sciencemuseumgroup.org.uk/objects/co8985543/manual-paper-tape-editing-equipment-for-programming-the-ferranti-mark-1-and-mark-1-computers ↩︎
4. https://ethw.org/First-Hand%3AIn_Her_Own_Words ↩︎
5. https://chsi.harvard.edu/harvard-ibm-mark-1-language ↩︎
6. https://www.computerhistory.org/revolution/mainframe-computers/7/172/696 ↩︎
7. https://www.computerhistory.org/revolution/story/172 ↩︎
8. https://www.ibm.com/software/shopzseries/ShopzSeries_public.wss?action=glossary ↩︎
9. https://groups.google.com/g/mod.sources/c/xSQM63e39YY ↩︎
10. https://www.rfc-editor.org/rfc/rfc1135 ↩︎
11. https://www.sei.cmu.edu/history-of-innovation/fostering-growth-in-professional-cyber-incident-management/ ↩︎
12. https://csrc.nist.gov/pubs/sp/800/40/r4/final ↩︎
13. https://www.computerhistory.org/revolution/punched-cards/2/4 ↩︎