What is Security Engineering?
Exploring the role, responsibilities, and impact
[AUTHOR, seated in his favorite writing chair (you know, one of those wooden ones that look, like, really cool yet uncomfortable), stares intently at his laptop’s screen. The eyes behind his glasses blaze with the fire of confidence, a confidence that rises from knowing he is about to craft another masterpiece, ready to sculpt his words from the marble of the blogosphere. He delicately lowers his hands onto his laptop, like a pianist setting the scene for the first note of Chopin. He begins to type.]
Merriam Webster’s dictionary defines “security engineering” as "isn't in the dictionary"…
[AUTHOR curses the dictionary gods. He lifts his gaze, staring into the distance, shocked that this dictionary-less thing is to be the focus of his next work.]
“Well, crap. No one’s ever started writing something by just copying a dictionary definition. I was sure I’d be the first… Now how am I supposed to start this post?,” he mutters to himself.
Surely there must be something just as brilliant as a copied dictionary definition for him to use?
[AUTHOR coughs gently into his right hand, hoping the reader doesn’t notice him frantically regathering his thoughts]
“Ahem,” he says, betraying his embarrassment ever so slightly.
“Let’s try this again, shall we?”
[AUTHOR begins typing once more.]
Many moons ago, when I first began crossing the river of career change, I remember how unsure I was about exactly what kind of career I wanted in tech. Working my way through school doing IT support, I knew I loved helping people, but I knew that tech support itself wasn’t my passion. I knew I enjoyed networking, especially the hands-on components (both CLI and with physical equipment), yet working with truly passionate network engineers I knew that likely wasn’t my place. Coding was incredibly rewarding and challenging, but something told me that I didn’t want to only program things for the rest of my life.
Eventually, as part of a two-year, corporate IT rotational program, I landed a six-month stint on my company’s enterprise security team. This was my first true exposure to security in a professional context and, through that rotation, I was afforded opportunities to conduct analysis, program solutions from scratch, and jump into real-world incident response efforts. I was hooked. From then on I knew that security was where belonged.
Here, I will dive into what I understand about the world of security engineering from my own experience. Also, I’ll rely heavily on reputable, not-me sources that are freely available so that you can form your own understanding of security engineering, too.
What actually is security engineering?
Raise your hand if you’ve ever started a school assignment or speech with something like, “Webster’s dictionary defines…”. I know I used to! And, while I was trying to give a snarky nod to ye olde tried-and-true method of beginning writing, the first step many of us take is to seek definitions for new terms, right?
Long, long ago, before the world was Google-fied, printed materials like dictionaries and encyclopedias were the first place people may go when seeking information on something new. You could thumb through the pages to get a researched summary about your topic of interest. Even in the early days of the internet, those trusted tomes that sat atop shelves were still what people would visit first, albeit digitally.
But, here we are in the year 2025, where trying to define something as new as “security engineering” is somewhat daunting. There are countless resources available, those well written and not, objective and not, and authentic and not. The challenge is that you, as the gatherer of knowledge, are supposed to determine what sources are reliable.
How does one start? How would you start?
Like any good blogger is wont to do, please allow me a moment to pretend that I have the knowledge coherently:
I define security engineering as the planning, building, maintaining, and optimizing of security controls, scoped to the needs and demands of the given context.
Now that I’ve gotten that moment of pride out of the way (bless you for letting me do that), here are some excellent resources that help paint a picture of what security engineering entails.
As LeVar Burton used to say in Reading Rainbow, “You don’t have to take my word for it!”
“Security Engineering” - Third Edition
This textbook, written by an English professor named Ross Anderson, was first printed in 2001 and revised twice more before his unfortunate passing in 2024. While Anderson had always made several chapters available for download, for free, through a University of Cambridge website, the university made all chapters fully available a few months after his death (a lovely gesture, I think).
Download all chapters of this seminal work here
Physical copies are available for purchase (I recommend only buying the latest edition with the green cover)
Ross Anderson was a stalwart presence in the global security community and his first chapter is devoted to the very purpose of defining security engineering. He begins Chapter 1 with:
Security engineering is about building systems to remain dependable in the face of malice, error, or mischance. As a discipline, it focuses on the tools, processes, and methods needed to design, implement, and test complete systems, and to adapt existing systems as their environment evolves.
Notice his use of broad terms like “building,” “systems,” and “tools”. As you explore security engineering as a topic, keep in mind how “security” encompasses many things, technical and not, and how “engineering” is not specific to coding alone.
Think about systems - What are some examples of technical and non-technical systems?
How might security factor into those systems that come to mind?
Also, take note of how Anderson calls out the constant need for evolution in security. Very few things in this world remain static and unchanging, so security engineering demands that professionals be nimble, adaptive, and capable of meeting the security needs of the moment.
The opening of this book is powerful as he eloquently states the purpose, need, and expectations of security engineering. His second paragraph continues on:
Security engineering requires cross-disciplinary expertise, ranging from cryptography and computer security through hardware tamper-resistance to a knowledge of economics, applied psychology, organisations and the law.
What a range of skills, right? He goes on to explain why a technical mindset alone is not enough:
System engineering skills, from business process analysis through software engineering to evaluation and testing, are also important; but they are not sufficient, as they deal only with error and mischance rather than malice. The security engineer also need s some skill at adversarial thinking, just like a chess player; you need to have studied lots of attacks that worked in the past, from their openings through their development to the outcomes.
In two paragraphs we have been told that security engineering demands that a slew of skills and acquired knowledge from many different areas. I’m a fan of Anderson’s definition in Chapter 1 because he gets straight to the point. He is telling us all that security engineering is remarkably complex, demanding, and, most importantly, that it may not be exactly what you think it is.
Side note: I swear I read beyond the first two paragraphs.
For aspiring security engineers and/or security professionals, this book is, hands down, my primary recommendation
It’s both FREE and fantastically thorough. For real. It’s a beautiful combo, right?
I just wanted to add another bullet—That first reason is reason enough!
Seriously, download this book (or purchase a copy).
Let’s jump into another resource for defining security engineering.
NIST
While Ross Anderson’s book above is the best recommendation I can make for anyone, NIST provides perhaps the most succinct and appropriate definition for security engineering:
An interdisciplinary approach and means to enable the realization of secure systems. It focuses on defining customer needs, security protection requirements, and required functionality early in the systems development lifecycle, documenting requirements, and then proceeding with design, synthesis, and system validation while considering the complete problem.
That’s it. Like I said, it’s succinct!
However, look at how NIST highlights “interdisciplinary” in a similar way to Anderson. Security engineering truly demands a focus across multiple disciplines.
Also, I love their phrasing of, “enable the realization of security systems”. In my own terms, I say “building”, but, I’m also not a well-staffed governmental organization full of fabulous professionals with stellar vocabularies. “[Enabling] the realization” of systems may mean planning, may mean research, may mean systems design, or it may mean a thousand other things.
My main point with these first two sources is to challenge your thinking of the term engineering and hopefully broaden your concept of the term.
The GitLab Handbook
GitLab is a code repository management platform that is available both in open source and paid flavors, depending on your use case. Their product relies primarily on Git, a file management system that also allows you to manage the versioning of files under its control. GitLab now bills itself as a wholistic DevSecOps management platform, but, for our purposes here, the main differentiator for GitLab is that you can use their cloud offering or host it yourself on your own systems (as opposed to GitHub, which is cloud-based).
Interested in learning more about Git?
Codecademy offers a free interactive, introductory course: Learn Git & GitHub
Looking for a completely open source offering for Git?
Check out Gogs - 100% free and open source
In addition to making their product open source, GitLab has graciously offered their GitLab Handbook to the world. Their handbook, shared publicly, houses all kinds of knowledge about GitLab from the mundane to the detailed, from typical “company handbook” kind of language to deep dives into internal workings, values, and decision making. For job seekers, GitLab posts detailed information about each role, and not just about the role itself, but every level of that role.
Speaking of levels, GitLab lists Security Engineer roles as a “grade 6” role, an intermediate position in GitLab parlance. You will very rarely see security engineering positions set to a lower grade.
Their handbook is a monstrosity (in a good way), so take some time to swim around.
Fortunately for us, those curious about security engineering, they pull back the curtain to reveal how they define security engineering at GitLab.
What I love about their write up is how they separate hard skills that are necessary for the role, explain the general responsibilities to be expected, and showcase the different areas of focus that exist for security engineers at GitLab. Their general requirements are:
You have a passion for security and open source
You are a team player, and enjoy collaborating with cross-functional teams
You are a great communicator
You employ a flexible and constructive approach when solving problems
You share our values, and work in accordance with those values
Ability to use GitLab
Aside from the final bullet, the rest of this is very run-of-the-mill when it comes to job descriptions you’ll see when job hunting. However, what’s great is how they have made these basic requirements so broad that it opens the door for a wide variety of educations, experience, and expertise.
Let’s highlight a couple of these generic points:
You have a passion for security and open source
If I were to ask you, “Do you have a passion for security?”, what would you say? Do you think that listening to podcasts is enough, or do you have a portfolio that you could share which demonstrates your passion?
For job seekers, this is critical - take time to reflect, brainstorm, and put pen to paper on exactly how you’d articulate your passion for security.
Practice your reply! No, seriously. Stand in front of a mirror and practice. Build your confidence in both material and tone of voice (written or spoken) so that you nail it come interview time. This is especially true for entry level/lower level roles.
The open source community is a global community that is a passionate one in and of itself. While contributing to an open source project is a major feather in your cap, don’t think that you have to be an open source maintainer in order to know about that world of tech. There are many open source products that you can install yourself, run locally, then learn as you go. Simply being familiar with and knowing how to use different open source offerings will add an extra dash of sparkle to your resume.
I know this article isn’t about passion, but, think about it—if you were to say you were passionate about something, could you explain why you’re passionate? In the tech world, you will hear everyone say that they’re passionate about one part of their job or another. Make yourself stand out by being prepared to explain and showcase why you’re passionate about tech.
You are a great communicator
Boy, do I love GitLab so much for including this! Kudos!
As a security engineer, you will be expected to communicate equally well with both technical and non-technical audiences. You may even be expected to share information with broader audiences, or perhaps the entire company. Please don’t be fooled whenever you see that communication skills are mentioned as “soft skills”. The ability to excel in communication is absolutely a hard skill, just as important as coding, and will be vital your career.
Think - How well do I communicate ideas, feelings, analysis/reports, etc. to others? Is my message clear? What is my tone and how are my communications impacting others? Can I adjust
Now, back to the technical stuff. We’ll keep leveraging the GitLab handbook because it’s awesome (and you should be leveraging it anyway)
Specialties within Security Engineering
GitLab also shares several specialties of security engineering.
This is helpful because, yes, you may be a security engineer, but at most larger companies you will have a primary area of focus. Depending on company size, you may be the only person within that specialty, or, if you’re lucky enough, part of a larger team that’s devoted to one thing in particular.
For the energy impaired (i.e. “lazy”, like me) I’ve included links below to the different specialties they list as I think it captures most of the specialties you’ll encounter in the wild:
Application Security
The cool kids call this “AppSec” for short (tech has a thirst for three-letter abbreviations of words - it’s a thing)
AppSec engineers tend to have strong backgrounds in software engineering, if not formal software engineering experience.
All companies have a given tech stack that they work with and list their tech within job descriptions. AppSec professionals need to have relevant experience and expertise in whatever the applicable tech stack is, or the ability to upskill into the tech of focus.
This is usually a highly technical role and may be deeply embedded within engineering teams.
Some excellent articles on AppSec (listed as the respective publishing company):
There’s an amazing set of Stanford lectures that is 100% worth a watch if you’re interested in foundational concepts. It’s a few years old but worth it’s weight in gold (19 videos in total). The course is CS 253 - Web Security:
Product Security
Just like with AppSec above, this is another heavily technical role that involves tons of time within a given codebase.
AppSec and Product Security are very closely related. As this article from CSO Online states, “Product security expands the scope of traditional application security well beyond testing and into the realms of advocacy, collaboration between business groups, design thinking, threat modeling, architectural planning and true risk management.”
However, Product Security engineers may be more heavily involved in the design and development stages, making sure that security is baked into a product from the onset.
This is a newer role that has grown out of the broader AppSec realm.
You may be assigned to a particular product or an specific part of the larger product your company builds, then be responsible for improving and testing its security. You could also easily be the Product Security Engineer for multiple projects at once.
This is another role that’s deeply embedded with software engineering. Software teams will rely on product security engineer to stay current with potential attack vectors, potential risks within the software supply chain, and any other security considerations that may be relevant for the assigned product.
NOTE: Hardware products are a thing, too!
You may be called upon as the go-to security resource should customers or prospective customers have questions about your product’s security.
Snyk offers a nice breakdown of the differences between Product Security and AppSec:
Here’s an area where I, too, want to learn more about! Check out these resources that I found informative:
Adobe has its own “Adobe Product Security Incident Response Team” (pretty cool)
In looking at potential resources, I noticed how large companies like Adobe have product security-specific IR teams, which is awesome.
Article by McKinsey & Company, Product security: Navigating regulations and customer expectations
This RSA Conference talk is interesting and serves as an primer for the field of Product Security: Infosec Makeover: Love it or Leave it, Product Security is Here to Stay
Signals Engineering
GitLab chose the word “Signals”, which I like, as it is generic to cover almost anything. You may also see '“Detection Engineering” or something similar at other companies. Some companies have signals engineering mixed in with broader security engineering roles.
There is plenty to dive into here - often you are expected to be, or become, a subject matter expert in your company’s SIEM tool and other tools that are responsible for handling event subscription data from many different systems
This easily ties into a realm that most are familiar with, Vulnerability Management, as many alerts correlate directly to a CVE/CWE or a specific vulnerability within a given technology
Just like how AppSec and Product Security engineers will also need to be abreast the latest vulnerabilities within a codebase, signals engineers will need to stay vigilant in regard to threat intelligence and security bulletins from reputable agencies
Most signals tooling will help greatly (breathe a sigh of relief in knowing you don’t need to know everything)
Depending on the company, you may be expected to have expertise concerning their SIEM of choice.
Further resources for signals/detection engineering:
Best article I can recommend: On the Road to Detection Engineering from the TrustedSec blog
A team member at TrustedSec gives insightful career advice, plus offers numerous resources for folks to dive into
Crowdstrike blog (can you tell yet that I like their stuff?), Wiz blog post (their blog is gold, always)
Here’s a really cool MITRE course that’s available for free on YouTube (33 videos in total): MAD20 Threat Hunting & Detection Engineering Course
SIRT - Security Incident Response Team
Any company with a security program will have some mechanism of incident response (sometimes called “IR”), even if it’s just listed in dusty policy documents somewhere.
Wiz maintains beautiful documentation on IR, so check it out: Incident response team depth chart
Atlassian also has wonderful information here, too, with many layers of detail.
“SIRT” itself isn’t a standard naming convention, with each company tending to have some flavor of that acronym. “CIRT” is also common. The name itself is less important than having an actual plan in place for how to handle an incident.
There may be dedicated incident response team members at a company, but what’s more likely is for security teams to have specific responsibilities, should an incident arise.
This means that they’re doing engineering or analyst work most of the time and only performing IR duties as needed.
Members of an incident response team may take on any number of responsibilities (see the Wiz article above). Here are some:
Incident commander = This is the primary point person for a given incident. They ensure that incident handling procedures are followed and are responsible for coordinating incident-related efforts. Communication skills are crucial for success in this role.
Tech lead(s) / Subject matter expert(s) = Your company’s policies may enforce the inclusion of specific technical team leads/company leads by default, but, typically, there are one or more technical experts brought into an incident if technical elements are involved. They may perform technical tasks directly or responsibly delegate tasks to their teams.
Communications lead = This individual brings communications expertise to the group and may be responsible for communicating to internal stakeholders, external parties (like customers), or the company at large. They are the ones who paint a picture of the incident to a given audience, likely taking information from other incident responders and carving a message that is both effective and appropriate. Communication skills are (obviously) critical here.
Legal / HR = This individual, or, more likely, these individuals, may be read-in depending on the type and scope of the incident at hand.
Legal counsel, whether full-time attorneys who work for the company or outside legal assistance, may be brought in to assess obligations according to the law, potential legal ramifications (if applicable), and general consultation.
HR is typically involved if there is direct impact to employees/employee information, or as a consultative resource when employees are involved with an incident. HR professionals may assist with gathering legal requirements or handling internal discussions.
There are many roles that a company may choose to assign, but, in the very least, incidents usually demand:
Someone to lead/coordinate the incident effort
Someone with the requisite skills to help (diagnose, fix, analyze, etc.)
Someone to communicate effectively, efficiently, and in a timely manner.
NOTE - One person may take on multiple duties (smaller organizations), or each team member may have specific responsibilities that are narrow in scope (typically larger organizations)
Incident response is a tremendously broad category (which might make a good article in the future…). Check out more information on IR from these companies:
SentinelOne, FireHydrant, CISA IR job role (pretty cool), National Cyber Security Centre
For a friendly, beginner-level introduction to incident response work, here’s the Incident Detection & Response videos from Google’s Cybersecurity Certificate (the best beginner certification, in my opinion).
They brought all of the individual videos together from the curriculum, combining them into one, long piece of content.
The supplemental materials are available for free in the description.
Google did amazing work in crafting this curriculum. I can’t recommend the Google Cybersecurity Certificate content enough for new learners.
In my opinion, the categories above are what most security engineers typically fall under. However, like I said before (props to LeVar Burton), “You don’t have to take my word for it”.
As GitLab demonstrates in their handbook, security engineers come in all shapes and flavors. Here are the other categories that GitLab lists as falling under the umbrella of “security engineering”:
Impact of Security Engineering
If you already have experience of some kind in a security discipline then you know that the term “security” is a broad term that yearns for specificity. Why? Because you can apply security practices, and therefore security engineering skills, to any number of areas within an organization.
This is why I spent so much time walking through GitLab’s security engineering specialties. People need to know that security engineering is more than just one discipline or set of skills. The real world demands agility and the ability for engineers to apply their problem solving skills to a range of issues.
People need to know that security engineering is more than just one discipline or one set of skills.
That’s it—problem solving. If I were to write a job posting for a security engineer today, I’d make sure to say how a great security engineer is a problem solving security engineer. And “problem solving” is a great way to put it. Separate those two words into their own categories and you have engineers that tackle the best of both worlds: investigate, analyze, and diagnose the problem while always ideating, proposing, and building the solution to the problem.
Security engineering, apart from a specific role, could easily be a mindset that you adopt as you dive into issues begging for a solution. Any realm of security has room for engineering excellence.
What a Difference a Title Makes
Before I release you from this temporary prison of overly long articles, I want to make a point about job titles. Some of you may already be engineers by title, and some of you may be sitting in other, non-engineering roles and seeking to work into the engineering field. There also might be a portion of you who don’t even work in security at all and are soaking up knowledge, preparing for career change.
Words don’t do justice for how excited I was when I promoted to Security Engineer (also, I don’t think I have enough brain juice left after writing to add anything flowery enough). I was seriously overjoyed! And, in all seriousness, one of my main drivers nowadays is to help others achieve their career aspirations, knowing how much it meant for me to achieve one of mine.
However, while titles are important, they do not define you. Security engineers rarely only engineer. I’ve seen security engineers do project planning, incident handling, customer communications, audit planning, and even the super thrilling work of documentation writing. As with any role, the organization and/or the situation may demand sets of skills that lay outside of security engineering itself. This is a major reason why I love the wide net that GitLab casts when it describes its security engineers. GitLab recognizes how security engineering skills touch across many, if not all, areas of the business.
Furthermore, you could be performing security engineering tasks without the title of Security Engineer. I’ve seen IT Help Desk teammates jump into automation work, Security Analysts script solutions that check for compliance tasks, and I’ve seen many software engineers who have a knack for security and incorporate those principles on a daily basis.
If you’re not a security engineer and you want to become one, start looking for areas of opportunity to apply security within your day-to-day work. I can’t encourage this enough! Widen your perception of “engineering” to be “building” instead and you will start to see a world of possibilities before you.
In general, I know that my tech career journey is not very unique. Lots of people transition from non-technical careers into tech and lots of people get their start in IT support and work their way up. Then, lots of people are dedicated to breaking directly into security itself. For me, I stumbled into security and then fell in love with building solutions that solve security problems and I enjoy my work. 10/10 would recommend.
Am I an engineer? Absolutely. Are there many different kinds of engineers? Absolutely.
Am I the best engineer I know? Absolutely NOT (there are people I know who could beat me in their sleep).
Do you have to be a god-level techie before you can become an engineer? Absolutely not.
Hopefully this post has helped to tickle that itch of curiosity you had for security engineering. Please share your thoughts below or reach out!