Must-Have vs Nice-to-Have: Structuring Skill Requirements for DevSecOps Roles

Most DevSecOps job postings list 15 or more requirements with no ranking. A candidate cannot tell which line gates the hire, and an applicant tracking system just counts keyword matches. 

The fix is a short, repeatable test applied to every line before the posting goes live, sorting each one into must-have or nice-to-have. 

This article uses one skill most postings mis-file, design-phase threat modeling, as the running example, with the Certified Threat Modeling Professional (CTMP) certification as the test case for structuring the requirement correctly.

Why Most DevSecOps Postings Get This Sorting Wrong

A requirements list is rarely written by one person with a full picture of the role. It is usually assembled from input by three groups.

1. Security asks for compliance familiarity.
2. Engineering asks for tool experience.
3. HR asks for years of experience and a degree, because those fields are easy to screen in bulk.

None of these stakeholders is wrong on their own. The problem is that nobody merges the three lists into a hierarchy.

The result is a posting where a tool name and a soft skill sit in the same tier as core security ownership. “Experience with Jenkins” and “can independently threat model a new service before it ships” read as equally weighted bullet points. Only one of those two lines actually determines whether the hire can do the job on day one.

Recruiters see the downstream effect constantly. One 2026 analysis of DevOps hiring found that stacking 15 or more skills onto a posting when only five are actually critical scares off qualified candidates who would otherwise apply and thrive in the role. A separate survey of recruiters found something similar: 65% report a surge in underqualified candidates applying for specialized roles, because postings do not signal which lines are firm.

What an Unsorted Posting Actually Looks Like

Pull almost any senior DevSecOps posting off a job board. The qualifications section usually reads like this, all in one undifferentiated block.

1. Bachelor’s degree in computer science or related field.
2. 5+ years of experience in DevOps or security engineering.
3. Strong understanding of secure coding practices.
4. Experience with AWS, Azure, or GCP.
5. Familiarity with container orchestration.
6. Excellent communication and collaboration skills.
7. Knowledge of threat modeling and secure design principles.

Every line reads with the same weight. Nothing tells a candidate that the degree line is negotiable, or that the cloud platform line means one of these three rather than all three. Nothing tells them the last line, in most organizations, is the one requirement that actually determines whether the hire can own architecture decisions on day one.

The hiring market makes this worse. Roughly 37% of IT leaders cite DevOps and DevSecOps as their single biggest technical skills gap, and DevSecOps-titled roles routinely pay $20,000 to $40,000 more than a standard DevOps role at the same level. When demand outstrips supply that badly, an unsorted posting does more than annoy candidates: it pushes the strongest ones toward a competitor’s posting that bothered to rank its own requirements.

None of this requires a new template. It requires applying one filter, line by line, before the posting is published. That is exactly how to write a DevSecOps job post that filters candidates instead of scaring off the people you actually want.

Sample Job Description

Senior DevSecOps Engineer (Security Architecture) Copy this template directly into your ATS. It applies the must-have vs nice-to-have sorting test from the main tab, with the Certified Threat Modeling Professional (CTMP) written in as a genuine gate rather than a vague design-principles line. Job Title Senior DevSecOps Engineer, Security Architecture Location and Type [Remote / Hybrid / On-site, city]. Full-time. About the Role We are hiring a Senior DevSecOps Engineer to own security architecture decisions across our CI/CD pipeline and production services. This role signs off on design reviews before implementation starts, not after a scanner flags a problem in testing. What You Will Own 1. Lead design-phase threat modeling for new services and major architecture changes. 2. Integrate threat models into CI/CD as living artifacts, not one-time documents. 3. Translate design-phase findings into risk-prioritized reports for engineering and compliance stakeholders. 4. Automate SAST, DAST, and SCA checks across the pipeline. 5. Partner with product and compliance teams on regulated data flows. Must-Have Requirements 1. Every line below gates the hire. A candidate missing any one of these is not a fit for this role. 2. Certified Threat Modeling Professional (CTMP) or demonstrated equivalent experience threat modeling production systems, including a portfolio example or a walkthrough of a real design review. 3. Can independently run STRIDE, PASTA, or a comparable methodology against a new service’s data flow diagram, without needing another engineer’s sign-off first. 4. 2+ years hands-on experience building or maintaining CI/CD pipelines (any of GitLab CI, GitHub Actions, Jenkins). 5. Working knowledge of at least one cloud platform (AWS, Azure, or GCP). 6. Can write a security finding a non-security stakeholder can act on, not just a list of vulnerabilities. Nice-to-Have Requirements These strengthen an application but do not disqualify a candidate on their own. 1. Experience threat modeling AI or ML pipelines specifically. 2. Familiarity with container orchestration (Kubernetes, Docker Swarm). 3. Prior experience mentoring or upskilling engineers into design-review ownership. 4. Exposure to compliance frameworks such as PCI-DSS, HIPAA, or SOC 2. 5. A degree in computer science or a related field. Not Required for This Role Advanced certifications in adjacent domains (container security, API security) are welcome but not evaluated as a gate for this posting. How We Verify the Must-Have Line We will ask you to walk through one specific threat modeling exercise or exam challenge in detail during the interview: the scenario, the framework you applied, and the tradeoff you made under time pressure. A credential link is checked against the issuer’s public verification page (for CTMP) before the offer stage. Compensation [Salary range]. DevSecOps-titled roles in this scope typically run $220,000 to $240,000 above a standard DevOps role at the same level. How to Apply Submit your resume along with either your CTMP certification link or two to three sentences describing a real design review you led. Applications without a verifiable threat modeling example will be reviewed after those with one.

The Must-Have Test

A requirement earns must-have status only if the role fails without it on day one. Not eventually, and not in some hypothetical future project. That single sentence is the whole test, but it helps to break it into three questions.

Ask these three questions of every line on the posting.

1. Does the role make security-relevant decisions independently, without needing someone else to sign off first?
2. Does a gap in this skill create direct risk exposure to the business, rather than a manageable inconvenience?
3. Can the skill be verified through work product, credential, or demonstration, rather than only claimed on a resume?

A line that fails any one of these three questions is not a must-have. It might still belong on the posting as a nice-to-have, or it might not belong at all.

This test also doubles as an ATS check. Applicant tracking systems rank resumes by counting how many posted keywords appear, with no concept of which keywords the hiring team actually meant as gates. A posting that puts “5+ years experience” and “can design a threat model” in the same unranked block trains the ATS to treat them as equally important, so a resume padded with tenure can outrank a resume that shows real design-review work. Sorting requirements before the posting goes live fixes more than the candidate experience: it is also the only way to make the ATS’s own keyword matching produce a ranking that reflects reality.

Two worked examples make the difference concrete.

“5+ years of experience” fails the test outright. It does not verify a skill, it verifies tenure, and tenure is a weak proxy at best. A candidate can spend five years doing the same shallow work on repeat, while a candidate with two years of intense, hands-on ownership can outperform them. Years of experience belongs, if anywhere, in the nice-to-have column, never as a gate.

“Can design a threat model for a new service before implementation starts” passes on all three counts.

1. It names a decision the role makes independently.
2. A gap here means design flaws ship into code, where they cost far more to fix.
3. It is verifiable. A candidate can walk through a real data flow diagram, name the trust boundaries, and explain what they flagged and why.

Requirement type	Independent decision?	Direct risk if missing?	Verifiable?	Verdict
“5+ years experience”	No	Indirect	No	Nice-to-have at most
“Familiar with security best practices”	No	Indirect	No	Cut or rewrite
“Can design a threat model for a new service”	Yes	Yes	Yes	Must-have
“Experience with a specific SAST tool”	Sometimes	Sometimes	Yes	Depends on role scope
“Strong communication skills”	No	No	No	Nice-to-have, if kept at all

Notice what the test does not do. It does not tell you to remove every soft requirement. It tells you to stop letting an unverifiable line occupy the same tier as a load-bearing one. A Senior DevSecOps Engineer role can still mention communication skills, it just cannot let that line crowd out the requirement that predicts whether the hire can own a design review.

Where Threat Modeling Fits, and Why It Gets Mis-Filed

Threat modeling is a design-phase skill, and that timing is the entire argument for where it belongs on a requirements list. Catching a design flaw before a single line of code ships is categorically cheaper than catching the same flaw in a penetration test, and dramatically cheaper than catching it after a breach.

The economics behind that claim are not new. NIST’s 2002 planning report on inadequate software testing infrastructure estimated the resulting drag on the US economy at between $22.2 billion and $59.5 billion a year. The report’s core finding: a large share of that cost traces back to defects caught too late in the lifecycle.

Despite that, most DevSecOps postings either omit threat modeling entirely or bury it under a phrase like “familiarity with secure design principles.” That phrase is unfalsifiable. A candidate can claim familiarity with almost anything and never be tested on it, so the requirement filters nobody. It is the same failure mode covered when writing a DevSecOps job post that attracts qualified candidates: vague phrases instead of verifiable ones.

Here is the reframe that fixes the mis-filing. For any role that owns architecture or design review, threat modeling is not a nice-to-have skill sitting next to the job. It is the mechanism that makes every other security requirement on the posting enforceable earlier and at lower cost.

Consider what a role loses without it.

1. Security requirements written into the SDLC stay aspirational, because nobody checks the design against them before implementation starts.
2. Vulnerability findings arrive later, during testing or after release, once cost to fix has already multiplied.
3. Architecture decisions get made without a documented threat model, so audits and compliance reviews have nothing concrete to point to.
4. The team relies on a scanner catching what a design review would have caught for free, weeks earlier.

Threat modeling itself is not one technique. Practitioners apply frameworks like STRIDE, PASTA, VAST, and LINDDUN depending on the system and the threat surface. Most start from a threat modeling data flow diagram, which maps how data moves before any threat gets classified. A role that owns design review needs someone who can pick the right method for the system in front of them, not someone who memorized one acronym for an interview.

Why the Mis-Filing Persists

Threat modeling does not produce a visible artifact the way a shipped feature does. A pull request is easy to point to in a performance review. A threat model that prevented a flaw from ever being written down as code leaves no obvious trace, the trace it leaves is the absence of an incident.

That invisibility makes it easy for a hiring manager to underrate the skill when writing the posting. They can point to a scanner’s output and see exactly what it caught. They cannot as easily point to what a threat model prevented from existing in the first place, so the requirement gets written as an afterthought instead of a gate.

That range of technique is exactly why “familiarity with secure design principles” cannot function as a real requirement. It gives no signal on whether the candidate can actually run the STRIDE process end to end, choose among the ten common threat modeling methodologies, or produce a usable model under time pressure. A verifiable credential closes that gap, and that is where a structured requirement, not a vague phrase, earns its place on the posting.

Structuring the Requirement: Certified Threat Modeling Professional (CTMP)

For any role that owns system architecture or design review, the posting should require or strongly prefer a verifiable, hands-on threat modeling credential, not a vague design-principles line. The Certified Threat Modeling Professional (CTMP) from Practical DevSecOps is built specifically to close that gap. Here is what it actually verifies.

What CTMP Verifies

CTMP is a vendor-neutral, hands-on program built around more than 40 browser-based labs. Candidates apply STRIDE, PASTA, VAST, and LINDDUN across three architecture types.

1. Cloud-native systems.
2. AI and ML pipelines.
3. Traditional monolithic applications.

That range matters. A candidate who can only threat model a monolith is not prepared for a team shipping microservices or LLM-backed features next quarter.

The course also teaches threat modeling as code, the practice of integrating threat models into CI/CD rather than treating them as a one-time document written once and never revisited. Ask a candidate about this directly, it is the difference between a threat model that stays current as the architecture changes and one that goes stale the week after the design review meeting ends.

A third pillar covers risk prioritization and stakeholder communication. A candidate who can identify a threat but cannot translate it into something a product manager can act on has only done half the job. CTMP’s labs push candidates to produce findings a non-security stakeholder can actually use, framed as business risk rather than a list of acronyms.

The syllabus breaks down into a handful of modules. Mapping them against a posting’s actual responsibilities is worth doing before deciding must-have versus nice-to-have.

Syllabus area	What it covers	Maps to which posting responsibility
Threat modeling foundations	Core concepts, trust boundaries, data flow diagrams	Any role touching design review
STRIDE, PASTA, VAST, LINDDUN	Method selection across architecture types	Security Architect, DevSecOps Engineer
Threat modeling as code	Integrating models into CI/CD pipelines	DevSecOps Engineer, Platform Engineer
Agile threat modeling	Fitting design review into sprint cadence	Any team running Scrum or Kanban
Privacy impact assessments	Applying LINDDUN and privacy-by-design	Roles handling regulated or personal data
Reporting and deliverables	Translating findings for non-security stakeholders	Any role that presents to product or compliance

A posting that names one or two of these modules directly gives a candidate something concrete to self-assess against, far more useful than the umbrella phrase “secure design principles.”

Proof Points Worth Verifying

The exam format is the part a skeptical hiring manager should press on. Format separates a credential that tests recall from one that tests capability.

1. The exam is a 6-hour practical, task-based exam, not multiple choice.
2. Candidates solve five challenge-based tasks mirroring scenarios covered in the course labs.
3. After the 6-hour session, candidates get 24 hours to write and submit a findings report.
4. The course includes more than 40 hands-on labs across the three architecture types.
5. Completion earns 24 CPE points.
6. The certification carries lifetime validity, with no recertification cycle.
7. Course access includes three years of videos and checklists, 60 days of browser-based lab time, and access to a dedicated support channel.

That exam format is worth repeating in the posting itself. It turns a certification line into something a hiring manager can interrogate in an interview. A candidate who passed can walk through a specific challenge they solved, in detail, the same way they would walk through a real production incident.

Trust Signal

CTMP is behind other hands-on credentials.

1.  Certified DevSecOps Professional (CDP).
2. Certified AI Security Professional (CAISP).

The organization has trained more than 12,500 security professionals and is listed in the NICCS Education & Training Catalog, the training catalog maintained by CISA, the US Cybersecurity and Infrastructure Security Agency.

For an HR team evaluating whether to write CTMP into a posting, the CTMP certification and exam page lays out the current syllabus, pricing, and exam process in full.

Upskilling an Existing Team Instead of Hiring Externally

Not every organization needs to fill this gap through an external hire. An engineer who already understands the codebase, the architecture, and the release cadence is frequently a faster path to design-review ownership than an unknown external candidate.

Because CTMP is self-paced, with three years of video access and 60 days of active lab time, it fits around an existing engineer’s current workload rather than requiring them to step away from their team for weeks. That makes it a reasonable option for a hiring manager who would rather grow the requirement internally, since external hiring cycles for senior technical roles currently run 49 to 62 days on average.

For teams upskilling more than one engineer at a time, the same course supports bulk enrollment, so a Security Architect and two DevSecOps Engineers can go through the same labs on the same timeline. Sending one engineer through a course alone builds an individual skill. Sending a small group through it together builds a team habit, which is closer to what a mature design-review process actually needs.

Where CTMP Does Not Fit

It is worth being equally direct about where this credential does not belong.

1. A Site Reliability Engineer role focused purely on uptime and incident response gains little from a threat modeling credential, since that role does not own design decisions either.
2. A short-term contractor brought in to fix one narrowly scoped bug is not the audience for a six-hour practical exam.

Naming these exceptions plainly keeps a must-have list honest, and stops the list from becoming a checklist applied uniformly across every posting a company writes.

Exact Posting Language: Must-Have vs Nice-to-Have Template

Once a requirement passes the must-have test, write it into the posting in language a candidate and an ATS can both parse without ambiguity.

For roles that own architecture or design review, the requirement should read as a genuine gate:

“Required: Certified Threat Modeling Professional (CTMP) or demonstrated equivalent experience threat modeling production systems.”

For roles that touch design occasionally, the same skill still deserves a mention, just in a softer register:

“Preferred: Threat modeling experience using STRIDE, PASTA, or a comparable methodology.”

The difference between those two lines is not cosmetic.

1. The first tells a candidate the line is a gate they need to clear before the interview starts.
2. The second tells them it is a plus that will help their application stand out, but will not disqualify them on its own.

Both are honest. An unsorted posting that uses neither phrasing forces every reader to guess.

Applying this across role types produces a clear table, worth pasting directly into an internal hiring rubric.

Role type	Threat modeling requirement	Where CTMP sits
Security Architect	Owns design review for the org	Must-have
DevSecOps Engineer with design input	Contributes to architecture decisions	Must-have
Junior Engineer	Learning the role, not yet owning design	Nice-to-have
QA / Test Engineer	Tests implementation, not design	Not listed

A few notes on using this table honestly.

A Security Architect role that lists threat modeling as a nice-to-have is under-specifying its own core function, and it will attract candidates who cannot do the part of the job that matters most.

A Junior Engineer posting that lists CTMP as a hard requirement filters out people who could grow into the skill on the job, which shrinks the applicant pool for no real benefit.

QA and Test Engineer roles are the honest exception. These roles validate implementation against requirements, they are not making design-phase decisions, so listing threat modeling at all risks diluting the posting’s actual must-have list. Leaving it off is not an oversight, it is the correct application of the same test used everywhere else in this doc.

Adapting the Template for AI and Platform Roles

The same split extends cleanly to roles that did not exist in most orgs a few years ago.

An AI Security Engineer job description that omits design-phase threat modeling for model pipelines is making the same mistake as a traditional Security Architect posting, just with a newer system type in play.

A Platform Engineer role that owns the internal developer platform, but does not sign off on individual service designs, sits closer to the nice-to-have column, similar to the DevSecOps Engineer with occasional design input above.

One more posting-language detail worth getting right. Avoid writing “threat modeling experience preferred” as a standalone line with nothing else around it. Pair it with the specific methodology or deliverable you want to see, so the line still passes the verifiability half of the must-have test even sitting in the nice-to-have column.

Verifying the Requirement Before You Trust It

A requirement is only as good as the process behind confirming it. That applies to certifications just as much as to years-of-experience claims.

Run these three checks before trusting any credential line on a resume.

1. Check the exam format. A practical, task-based exam that produces a real deliverable verifies far more than a multiple-choice test that only checks recall.
2. Check whether the credential requires producing an actual threat model and defending it, rather than just answering questions about the theory behind one.
3. Check whether the issuing body is listed on an independent catalog, such as NICCS, rather than only appearing on the vendor’s own marketing pages.

The verification step itself is simple. Ask the candidate for a credential link, then confirm it against the issuer’s public verification page. Practical DevSecOps badges are hosted on Credly specifically so this check takes thirty seconds, not a phone call.

This same standard should apply consistently across every credential a posting names. A hiring manager who verifies a threat modeling certification but waves through an unverified “5+ years” claim on the same resume has only closed half the gap.

The exam and certification process page documents exactly what a CTMP candidate goes through, useful reading for anyone building an internal verification checklist.

There is also an interview-stage check worth running alongside the credential check. A candidate who genuinely holds a hands-on, task-based certification should be able to describe one specific exam challenge in detail: what the scenario was, which framework they applied, and what tradeoff they had to make under time pressure.

This extends the kind of scenario-based questioning already covered in a good set of DevSecOps interview questions, and it is far harder to bluff than a general question about threat modeling theory.

A resume line and a verification page confirm that the credential exists. A specific, detailed answer in the interview confirms the candidate actually did the work behind it.

The ROI Case for Sorting This Correctly

Sorting requirements correctly carries a direct cost argument well beyond hiring hygiene. The argument starts with how much cheaper a design flaw is to fix the earlier it is caught.

The general pattern, documented across decades of software economics research including NIST’s report on inadequate testing infrastructure, is that the cost to fix a defect rises sharply the later it is found.

1. A flaw caught during design review might cost a rewritten paragraph in a document.
2. The same flaw caught during a penetration test costs a debugging cycle, a rebuild, and a retest.
3. Caught after a breach, it costs incident response, customer communication, and often regulatory exposure on top of the original fix.

Discovery stage	What fixing it typically requires	Relative cost
Design review	Revise a document or diagram before code exists	Baseline
Implementation	Modify code, recompile, rerun unit tests	Several times baseline
Testing / QA	Reproduce, debug, rebuild, retest	An order of magnitude above baseline
Production / after a breach	Incident response, customer communication, regulatory exposure, secondary fixes	Tens to over a hundred times baseline

Exact multipliers vary by study, team, and system complexity, and the specific numbers have been debated since the underlying research was first published. What has not been debated is the direction of the curve: it only ever goes up as a defect travels further through the lifecycle before it is caught. That is the entire economic argument for hiring someone who can catch design flaws before they become code.

Set the certification’s cost against that backdrop. CTMP costs $899. Compare that single figure against the cost of a missed design flaw that reaches production, or against the cost of a mis-hire in a role meant to own design review, and the certification cost reads as a rounding error.

Cost driver	Typical exposure	CTMP cost
One design flaw caught late, requiring rework and retest	Thousands of dollars in engineering time	$899, one time
One mis-hire in a design-owning role	Months of salary, plus the flaws that shipped in the meantime	$899, one time
A breach traced to a missed design-phase risk	Incident response, regulatory exposure, reputational cost	$899, one time

This is the same ROI logic that applies across the other credentials in this series, from container security to API security. Design-phase and pre-production verification is consistently the cheapest place to catch a problem.

There is a second, less obvious cost that a sorted posting avoids: the cost of the hiring cycle itself. Offer acceptance rates for DevOps and DevSecOps-adjacent roles have fallen in recent years, as candidates compare multiple offers and lean toward postings that read as specific and well thought out.

A posting that clearly separates a genuine gate from a nice-to-have signals to a strong candidate that the hiring team has already done its own homework, a small but real factor in whether that candidate accepts the eventual offer.

None of this argues for treating a certification as a substitute for judgment during the interview itself. It argues for using a verifiable, hands-on credential as the fast, honest filter that gets the right candidates into that interview in the first place.

The ROI case also compounds across a hiring plan rather than staying isolated to a single requisition. An organization filling three Security Architect roles a year, each carrying the same sorted must-have list, gets three candidates who can walk into design review on day one, instead of three who need months of ramp-up first. Multiply the earlier design-flaw cost table by even a handful of avoided late-stage fixes across those hires, and the certification cost becomes negligible against what a single missed design flaw would have cost on its own.

Final Thoughts

Sorting requirements is not about writing a longer posting. It is about being honest with yourself, and with the candidate reading it, about which lines on the list are actually load-bearing.

A “5+ years” line and a verifiable, hands-on threat modeling credential are not equivalent signals. Treating them as equivalent is what produces a fifteen-line posting nobody can parse.

For HR teams building the next posting, run every line through the three-question test in this doc. Then check the current CTMP certification page before deciding whether it belongs in the must-have or nice-to-have column.

For candidates eyeing a design-owning role, the honest move is to earn the credential before applying, not after an interview reveals the gap. A CTMP course and certification is a defined, verifiable way to close that gap on your own schedule.

The broader lesson extends past this one skill. Every requirements list in every DevSecOps posting deserves the same three-question test.

1. Does the role make this decision independently?
2. Does a gap create direct risk?
3. Can the skill actually be verified?

Apply it consistently, across every line. The posting stops being a wish list. It starts being a filter that works the way it was always meant to.

Certified AI Security Professional (CAISP)·7-day free trial

Open a live AI security lab in your browser today

Real targets, real terminals, no local setup.

Start your free trial
No credit card required.

caisp-lab-03

$ ./inject.py –target bot

[*] probing prompt boundary

[+] injection successful

$

Frequently Asked Questions