A developer once told me security was “the infrastructure team’s problem.”

He said this while sharing an API key in a Slack channel.

Nothing dramatic happened. The message was deleted a few minutes later. But that moment stayed with me because it captures how many people in tech think about security. They treat it as a separate department—some serious group that appears after a problem, asks uncomfortable questions, and blocks a release.

That view is outdated.

You don’t need to become a penetration tester or spend weekends studying encryption. But if your work touches software, customer data, cloud accounts or vendor access, security is already inside your job. Ignoring it doesn’t make it somebody else’s responsibility.

Most incidents begin with something boring

People love the dramatic version of cybersecurity.

A person in a dark room. Several monitors. Green text moving at unreasonable speed. Maybe a hoodie, because apparently air conditioning is a major concern among criminals.

Real problems are usually less cinematic. Someone reuses a password. A contractor keeps access after leaving. A test database ends up in public storage. An employee approves a login request because the notification appeared while they were ordering lunch.

Boring mistakes scale very well.

Basic security knowledge matters more than memorising famous attacks. Can you recognise an unusual login request? Do you know which data should not be pasted into an AI tool? Would you notice credentials in a GitHub repository?

These are ordinary work questions.

The password conversation is still not finished

I wish we had moved past passwords. We haven’t.

A friend once lost access to an old shopping account. He wasn’t worried until he remembered that the same password had been used for Gmail, a streaming service and two work tools. The shopping site barely mattered. The reused password did.

He spent the evening changing logins and trying to remember which variation included an exclamation mark.

Use a password manager. I’m opinionated about this. Human beings are bad at creating and remembering dozens of strong, unique passwords, and pretending otherwise has produced years of predictable nonsense.

Turn on multi-factor authentication too, especially for email, cloud platforms, GitHub, banking and administrator accounts. It adds a little friction. That is the point.

Security that creates zero inconvenience usually creates zero protection.

Developers don’t get a special exemption

A developer can write code that passes every test and still creates a security problem.

Normal testing asks whether the feature works. Security thinking asks what happens when somebody uses it in a way nobody intended.

Can one customer see another customer’s invoice by changing a number in the URL? Can an uploaded file contain something dangerous? Does the application reveal too much when a login fails? Are permissions checked on the server, or does the interface merely hide the button?

These questions are part of building software for actual users, including careless or hostile ones.

Here’s the thing. Fixing security after launch is usually miserable. By then, the weak assumption may have spread through the database, mobile app and three integrations nobody wants to touch. Thinking about it during design is cheaper and calmer.

Not exciting. Cheaper and calmer is good.

Product managers make security decisions too

Security failures are often described as technical failures, even when the real cause was a business decision.

A team removes a verification step because conversion is dropping. Customer support receives broad account access because narrower permissions will take another sprint. Logs keep sensitive information because nobody decided how long they should exist.

Those are product and operations choices.

If you write requirements, approve vendors or set deadlines, you influence security. Saying “engineering will handle it” avoids seeing the trade-off.

Sometimes a safer option will slow onboarding. Sometimes collecting less data will limit a feature. Sometimes a release should wait.

Nobody enjoys delaying the shiny thing. But “we’ll fix it later” has an impressive ability to become part of the architecture.

Convenience has a long memory

Tech workers connect tools quickly.

A calendar app wants access to Gmail. A meeting assistant wants recordings and transcripts. A browser extension wants permission to read every page. A free analytics tool asks for production data because the demo account looks empty.

Clicking Allow takes two seconds.

Removing that access six months later requires remembering it exists.

This is where security becomes less about hackers and more about inventory. Which tools can see customer information? Who still has administrator rights? Where are backups stored? Which old integration continues receiving data even though the team stopped using it?

I’ve seen companies debate airport Wi-Fi while dozens of forgotten accounts remain connected. The Wi-Fi question isn’t foolish. It’s simply more visible.

Invisible convenience tends to survive.

Updates are annoying for a reason

Everyone has postponed an update because they were busy, travelling or surrounded by thirty open tabs they didn’t want to lose.

Fair enough.

But updates often repair weaknesses, not just move buttons around. Delaying them indefinitely means keeping known problems alive because restarting feels inconvenient.

The same applies to libraries and dependencies. A project can sit untouched while the code underneath it ages.

Anyway, there is no realistic state called “finished and secure.” Systems need maintenance. Access needs reviewing. Backups need testing. People leave companies. Vendors change. New flaws appear in old components.

Security is a routine, not a certificate on a wall.

You mainly need better instincts

Most tech professionals do not need deep expertise in malware analysis or network forensics.

They need instincts.

Pause when a Slack message asks for an urgent payment change. Question why a tool wants broad permissions. Don’t paste production data into a random service. Report the strange email instead of quietly deleting it. Know where important files are backed up. Ask who can access the feature before asking whether the button looks right.

And when you make a mistake, say it quickly.

That habit matters more than people admit. Small problems become large while someone is hoping nobody noticed. A shared credential can be rotated. An incorrect permission can be removed. Silence is harder to repair.

Security teams can provide tools, policies and expertise. They cannot stand beside every developer, analyst, designer and product manager during every decision.

Nor should they have to.

The useful goal isn’t to make everyone paranoid. It’s to make carelessness feel slightly unusual—something you notice before clicking past it.