Secure Custom Software: What a Well-Run Project Looks Like

Why Custom Software Needs the Same Discipline as Infrastructure

Nobody would let a contractor reconfigure the firewall with no record of what changed. Custom software deserves the same care, because the risk lives in two places:

• The data it touches. A billing integration reads customer names, amounts and sometimes card or bank details. A township records portal handles public records with retention rules. A clinic scheduling tool handles protected health information. The rules that apply to the data apply to the software that moves it.
• The access it holds. Glue code usually runs under a service account, often created in a hurry with administrator rights "to make it work." It becomes a standing key to your systems that nobody reviews or remembers to disable.

Custom software also outlives its author. The script a helpful employee wrote in 2021 is still running after they have left. The practices below let the next person understand it, change it safely, and prove to an auditor or insurer what it does.

Test-Driven Development, in Plain Terms

Test-driven development (TDD) means the developer writes a small automated test that describes "done" before writing the code that does the work. The test fails at first, because the feature does not exist yet. The developer then writes just enough code to make it pass. Three habits come with it:

• Every bug gets a test first. When something breaks, the developer writes a test that reproduces the failure, watches it fail, then fixes the code. That bug can never quietly return.
• Tests run automatically on every change. A continuous integration (CI) service runs the whole suite each time code is pushed, on a clean machine, without anyone remembering to do it.
• Red blocks the merge. If any test fails, the change cannot be merged into the main version. Nobody has to argue about it.

Here is what a test looks like for a simple late-fee rule. You do not need to read code to follow it:

test('no late fee on day 30', () => {
  expect(lateFee({ amount: 200, daysOverdue: 30 })).toBe(0);
});

test('5 percent late fee from day 31', () => {
  expect(lateFee({ amount: 200, daysOverdue: 31 })).toBe(10);
});

That business rule, written down before the code, is now checked on every change for the life of the software. If someone edits the fee calculation next year and gets the boundary wrong, the test goes red before a customer sees it.

Why this matters to someone who never reads the code: fewer surprises after an update, the ability to change the software safely years later with a different developer, and a dated record that each change was tested. That record is exactly the evidence an auditor asks for. It is how we build our own website, as described on our development page.

Security Built In, Not Bolted On

These controls are cheap on day one and expensive after an incident.

• Least-privilege access. Each piece of software gets its own service account with only the permissions it needs: read-only where it only reads, one database instead of the whole server. People get named accounts with multi-factor authentication (MFA), never a shared login.
• Secrets kept out of the code. Passwords, application programming interface (API) keys and connection strings live in environment settings or a secret store, never in the source files. Assume anything committed to a repository is readable by everyone who will ever see it.
• Dependency and supply-chain hygiene. Modern software is mostly other people's packages. Pin exact versions in a lockfile, so every build installs the same thing. Wait about a week before adopting a newly published version: in one review of ten prominent supply-chain attacks, eight of the poisoned releases were found and pulled in less than a week. A wait is not a guarantee, so keep the other checks too. Block package install scripts that do not need to run. Run a vulnerability audit in CI so a known-vulnerable package fails the build.
• Exposure checks. Internal files (configuration, documentation, test data) must never be publicly served. An automated test that requests those paths on the live site and expects "not found" catches a mistake before an attacker does.
• Private repositories. Source code and its history belong in a private repository that your organization controls, with access reviewed like any other system.
• Logging and an audit trail. The software should record who did what and when, in a place the application itself cannot erase. For public entities, check how long those logs and any records the software creates must be kept under your records commission's retention schedule (ORC 149.38 for counties, 149.39 for municipalities and 149.42 for townships; other public bodies have their own sections in Chapter 149).
• Backups and restore tests. Back up the data and the configuration, and restore them on a schedule to prove it works. Our offsite backup guide covers the restore record insurers ask for.

Cyber-insurance questionnaires ask about MFA, backups, patching and unsupported software. Custom code is software you must patch, so keep it on the same schedule as everything else (see our patch management guide), and scan what it exposes like any other system (see open-source versus commercial scanners).

Right-Sizing: Do Not Gold-Plate a One-Page Form

Every practice above scales down. Match the process to what the software touches.

Frequently Asked Questions