Cybersecurity fundamentals for developers: the CIA triad applied to real systems

Most developers meet security for the first time as a ticket: a scanner finding, a penetration test report, a customer questionnaire with 200 rows. The vocabulary in those documents assumes you already know the basics, and nobody stops to explain them. This series fills that gap, one topic per post, written for people who build software rather than people who audit it.

We start with the model that almost every security standard is built on: confidentiality, integrity and availability, usually called the CIA triad. By the end of this post you should be able to look at any feature you are building and say which of the three it puts at risk, and what control protects it.

Cybersecurity and information security are not the same thing

The two terms are used interchangeably, but they have different scopes, and the difference matters when you decide who owns a problem.

Information security is the larger circle. A printed customer list left on a train is an information security incident, but not a cybersecurity one. A stolen database backup is both. For a software team the practical overlap is almost total, but remember the larger circle when you design processes: exports to spreadsheets, screenshots in chat and support agents reading data aloud are all part of the problem even though no packet is involved.

Confidentiality: only the right people can read it

Confidentiality means information is disclosed only to people, processes and systems that are authorised to see it. It is the property most people think of first, because breaches make the news.

Where confidentiality fails in ordinary code:

• An API returns the full user object, including a password hash and internal notes, because the serializer was never restricted.
• A log line prints the whole request body, so card numbers and tokens end up in the log platform.
• An object storage bucket is readable by anyone with the URL.
• A support tool lets every agent search every customer, when they only need their own region.

Controls that protect confidentiality:

• Access control at the data layer, not only in the user interface.
• Encryption in transit (TLS) and at rest (disk, database, backups), with keys managed separately from the data.
• Data minimisation: the field you never store cannot leak.
• Masking and redaction in logs, analytics and non-production copies.

A useful habit: for every new field you add to a model, decide who may read it. If the answer is "anyone who can call the endpoint", write that down deliberately.

Integrity: nobody can change it without being noticed

Integrity means information and systems are accurate, complete and changed only in authorised ways. Integrity failures are often quieter than confidentiality failures, which makes them more dangerous: data can be wrong for weeks before anyone notices.

Typical integrity failures:

• A price or quantity is taken from the client request instead of the server-side catalogue.
• Two concurrent requests both read a balance and both write a new one, so one update is lost.
• A webhook handler trusts the payload without verifying its signature.
• A build pipeline downloads a dependency over plain HTTP, or without checking its checksum.

Controls that protect integrity:

• Input validation and server-side recomputation of anything that matters (prices, totals, permissions).
• Hashes, checksums and signatures on files, packages, messages and webhooks.
• Database constraints and transactions, so invalid states cannot be written.
• Audit logs that record who changed what, stored where the actor cannot edit them.
• Version control and code review for both application code and infrastructure.

Availability: it works when people need it

Availability means authorised users can access information and systems when they need them. A system that is perfectly confidential because it is switched off has failed at its job.

Availability is threatened by attacks, such as denial of service and ransomware, but far more often by ordinary engineering problems: a full disk, an expired certificate, a bad deploy, a dependency outage or a single database without a replica. Security teams care about these because the impact on the business is the same whatever the cause.

Controls that protect availability:

• Redundancy: more than one instance, zone or region for critical components.
• Backups that are tested by restoring them, and copies the attacker cannot delete.
• Capacity limits and rate limiting, so one client cannot exhaust shared resources.
• Monitoring and alerting on the signals that predict an outage, such as certificate expiry and disk usage, not only on the outage itself.
• Incident response plans, so recovery does not depend on one person's memory.

The three pull against each other

Real decisions are trade-offs between the three properties, and seeing them explicitly is the point of the model.

• Encrypting a database with a key held in a separate service improves confidentiality, but if the key service is unavailable, the database is too.
• Requiring two people to approve every production change protects integrity, but slows down an emergency fix and hurts availability.
• Keeping many replicas and backups improves availability, but every copy is one more place where confidentiality can fail.

There is no universal right answer. A public marketing site cares mostly about integrity (nobody should deface it) and availability. A medical record system cares about all three, with confidentiality usually first. Write down which property matters most for each system you own; it will make many later decisions easier.

Two more properties worth knowing

Many frameworks extend the triad with two further properties that come up often in application work.

Authenticity is confidence that a message, user or system is who or what it claims to be. Login, API keys, TLS certificates and webhook signatures all provide authenticity. Without it, integrity is hard to guarantee, because you cannot tell an authorised change from a forged one.

Non-repudiation means someone cannot credibly deny an action they performed. Digital signatures and tamper-evident audit logs provide it. It matters for approvals, payments and anything that may end up in a dispute: "the logs say user 42 approved the refund" is only useful if user 42 could not have been impersonated and the log could not have been edited.

Mapping incidents to the triad

Practise by classifying incidents. These are typical examples from small and mid-size companies:

Notice that most rows are not exotic attacks. They are design gaps that a developer could have closed during normal feature work.

A 20-minute exercise for your own system

Take one service you own and answer these questions in a shared document:

1. What data does it store or process? Mark each type as public, internal, confidential or restricted.
2. For each confidential or restricted type, who can read it today, and who actually needs to?
3. Which values must never be changed by a client? Where are they recomputed or verified on the server?
4. What would one hour of downtime cost? One day? Is the recovery procedure written down?
5. Which actions must be provably attributable to a person, and where is that recorded?

The answers become your first security backlog. Most teams find at least one access rule that is wider than needed and one recovery step that only exists in someone's head.

Key takeaways

• Information security covers information in every form; cybersecurity is the digital part of it. Software teams own most of the overlap.
• Confidentiality is about who can read, integrity about who can change, availability about whether it works when needed.
• Many availability and integrity failures come from ordinary engineering mistakes, not attackers, and they still count as security problems.
• The properties conflict; decide which one matters most per system and design for it.
• Authenticity and non-repudiation complete the picture for logins, payments and approvals.

The next part covers the networking basics you need to reason about exposure: addresses, ports and protocols, from a defender's point of view.

References

• NIST SP 800-12 Rev. 1, An Introduction to Information Security: https://csrc.nist.gov/pubs/sp/800/12/r1/final
• NIST Cybersecurity Framework 2.0: https://www.nist.gov/cyberframework
• NIST glossary entry for confidentiality, integrity and availability: https://csrc.nist.gov/glossary