PurPassionDigital / Everywhere
Cybersecurity / InfoSec · Digital / Everywhere

Security Engineer

Unexpected
Resolution · Broken FunctionalThe pull to make things work
Pace
  • A steady rhythm with room to breathe
  • A hard push you keep up for a long stretch
What your week looks likeMonday-to-Friday, roughly 9-to-5
How much you move around at workScreen and chair, almost all day
Whether you can work from anywhereWork from anywhere with a signal or internet connection
How quickly you receive feedback on your workA few weeks before the picture clears
What you're actually working withNumbers, measurements, records — things you read on a screen / Concepts, theories, designs, stories — things you think up

Core
  • Making processes run without constant human input.
  • Constructing from parts into a functional whole. Structural, assembled.
  • Applying systematic problem-solving to make things work reliably.
  • Building systems that make safety structural, not reactive.
Also present
  • Conceptual architecture. Figuring out how something should work before it exists.
  • Watching for danger, maintaining vigilance.
  • Taking something that works and making it work better.
  • Verifying whether something is true or works as claimed.

The security engineer builds the systems that make protection structural rather than reactive. Where the SOC analyst watches for threats and the pen tester finds vulnerabilities, the security engineer designs and implements the controls that prevent threats from succeeding and vulnerabilities from existing in the first place. The primary pull is Resolution — taking systems that are vulnerable by default and engineering them into systems that are secure by design. The work is creation in the service of protection: building authentication systems, configuring firewalls, implementing encryption, designing access control architectures, automating security scanning in deployment pipelines.

The daily texture is engineering. Security engineers write code, build infrastructure, configure systems, and review other engineers' designs for security implications. The work sits at the intersection of software engineering and security expertise — the security engineer needs to understand both how systems work and how they fail. The best security engineers are the ones who can think like an attacker while building like an engineer — who can look at a system design and see not just what it does but what it would do if someone were trying to break it.

The field increasingly lives in the "shift left" paradigm — moving security earlier in the development process rather than bolting it on after the fact. Security engineers embed in development teams, contribute to code reviews, build security tooling into CI/CD pipelines, and work to make secure development the path of least resistance rather than an obstacle developers work around. This is the Spread gradient in action: building security once in a way that scales across the entire development organisation.

🦊
There's a guide here if you want one

Kitsune can talk through anything on this page — whether it might suit you, what to do next, questions this page doesn't answer. Everything here is yours to read either way.

The most common frustration in security engineering is building things that other engineers actively work around. Security controls that add friction to the development process will be circumvented. The security engineer's design challenge is not just making systems secure but making the secure path easier than the insecure path — which is a fundamentally different engineering problem than most security training addresses.

The role is less visible than penetration testing and less dramatic than incident response. Security engineers rarely get credit when things go well because when things go well, nothing happens. The satisfaction is structural rather than episodic — the knowledge that the system you built is holding, that the control you implemented is preventing classes of attack that nobody ever sees.

The compliance dimension is larger than most entrants expect. A significant share of security engineering work in regulated industries (finance, healthcare, government) is compliance-driven — implementing controls required by frameworks like SOC 2, ISO 27001, HIPAA, or FedRAMP. The gap between what is intellectually interesting and what the regulatory calendar demands is a recurring source of tension.

Software engineering or systems administration background is the most common path. Security engineers are engineers who specialised — the engineering fundamentals come first. Computer science degrees with security coursework provide strong foundations. Certifications like CISSP and cloud security certifications (AWS Security Specialty, GCP Professional Cloud Security Engineer) carry weight. Some security engineers enter from penetration testing or SOC roles after deciding they prefer building to breaking. The field's labour shortage means that software engineers with demonstrated security interest can often transition laterally.