Skip to content
CertGPS
Career path

From Developer to Application Security: OWASP ASVS, SAMM and the Credentials That Test Code

How developers move into AppSec: the NICE work roles, OWASP ASVS 5.0 and SAMM as the yardsticks, and when CSSLP, GWEB, CASE Java or OSWE fits.

LT
Lisa Thompson
Security Training Director
Published
Updated
Read time
6 min
On this page

Related certifications

Topics

From Developer to Application Security: OWASP ASVS, SAMM and the Credentials That Test Code

A working developer already does part of the application security job. NIST's task lists for secure software development and software security assessment both include code reviews and spotting common coding flaws. The new skill is measurement. Application security (AppSec) teams check software against OWASP's Application Security Verification Standard (ASVS) and grade their own programs with OWASP SAMM, so learn both before you choose a certification.

Two NICE work roles with a shared task list

The NICE Workforce Framework (NIST SP 800-181) splits this territory into two work roles. Secure Software Development (DD-WRL-003) is the developer's own: develop secure code and error handling, perform code reviews, identify common coding flaws, prepare secure code documentation. Software Security Assessment (DD-WRL-005) is the AppSec engineer's, and it is described as analyzing the security of new or existing applications and "delivering actionable results". Its tasks repeat the code reviews and coding flaws, then add developing threat models and analyzing the vulnerabilities in software patches and updates.

So the move is shorter than it looks. The work you add is threat modeling, reviewing other teams' code rather than your own, and writing findings that someone else has to act on.

The Bureau of Labor Statistics (BLS) doesn't publish an application security occupation, so there's no government pay figure for the job itself. The two nearest occupations are software developers, whose May 2025 median pay BLS puts at $135,980, and information security analysts, at $129,180.

ASVS: the requirements you'll verify

ASVS is the closest thing AppSec has to a shared checklist. Version 5.0.0, released on May 30, 2025, holds about 350 requirements in 17 chapters, from encoding and sanitization through authentication, session management, OAuth and OpenID Connect, to logging. It has three levels. Level 1 is roughly the first 20% of requirements, the minimum starting point. Most applications should aim for Level 2, which brings the total to about 70%. Level 3 adds the final 30% for applications that need defense in depth.

OWASP lists ASVS uses that matter to someone changing jobs: a coding reference for developers, a basis for automated unit and integration tests, a training curriculum, and a standard buyers can write into software contracts. One caution comes from OWASP itself. It doesn't certify vendors, verifiers or software, and it warns that any "certification claiming ASVS compliance" is not endorsed by OWASP. So knowing the standard is something you demonstrate rather than certify.

Your own code is the place to do it. Take a service you maintain, work through the Level 1 requirements in the authentication (V6) and session management (V7) chapters, and write a test for each one it fails. In our view, a short write-up of what you found and fixed tells an AppSec hiring manager more than a course certificate.

SAMM and the SSDF: the program view

AppSec engineers also judge how an organization builds software, not only what it ships. OWASP's Software Assurance Maturity Model (SAMM) is a self-assessment with five business functions (Governance, Design, Implementation, Verification and Operations), three security practices in each, and three maturity levels per practice. Running a SAMM assessment of your own team is a project a developer can lead, and it teaches you the names AppSec teams use for their work, since SAMM's practices include Threat Assessment, Security Requirements, Security Testing and Defect Management.

For US government software work, also learn NIST's Secure Software Development Framework (SSDF). SP 800-218, version 1.1 from February 2022, describes a core set of high-level practices meant to fit into any development lifecycle. If you work for a vendor that sells to federal agencies, learn the SSDF as well, because customers will ask how your process maps to it.

The credentials, by what they test

CredentialWhat it testsExamPriceExperience
CSSLPSecurity across the software lifecycle, eight domains125 questions, 3 hours$599Four years in the domains; one can come from a degree
GWEBDefending web applications and APIs75 questions, 3 hours, 68% to pass$999None set
CASE JavaSecure coding in Java web applications50 questions, 2 hours, 70% to pass$450 voucherOfficial training, or two years in security or software plus a $100 application
OSWEFinding and exploiting flaws by reading source code47 hours 45 minutes of practical work, then a report$1,749 with 90 days of WEB-300None set; programming and web proxy skills recommended

CSSLP is the credential for the program side of AppSec. ISC2 asks for four years of cumulative work in one or more of its eight domains, which include Secure Software Implementation and Secure Software Testing. A developer who has been writing and testing secure code may already have some of that time, though ISC2 decides at endorsement. Without the four years you can pass and become an Associate of ISC2, with five years to earn them.

GWEB is the defensive web exam. GIAC aims it at application developers and security analysts as well as auditors and architects, and its objectives reach REST and GraphQL APIs. CASE Java is narrower. EC-Council runs it as a separate exam from CASE .NET, so the Java exam stays with Java web applications.

OSWE is the hard one. OffSec gives you nearly 48 hours to read the code of several web applications, find a chain of flaws, and write a script that exploits each target without anyone touching the keyboard. It suits a developer who wants proof they can find bugs in code rather than in scanner output.

A staged route from your current team

Start inside your own team. Volunteer to triage security findings from your scanners, run the ASVS exercise above, and threat model the next feature you build. You're ready to move on when you can explain each fix to another developer in terms of the requirement it meets.

Then practise attacking. PortSwigger's Web Security Academy is free, with 16 labs on SQL injection and 30 on cross-site scripting among many other topics, and OWASP Juice Shop is a deliberately insecure application you can run locally. The marker here is that you can find a flaw by reading the code first and confirm it in the running application afterward.

Pick the first credential by the job. For an engineering role that reviews code and tests applications, take OSWE, or GWEB if your employer pays for SANS training. For a security champion in a Java shop, CASE Java is cheaper and matches the stack. Save CSSLP for when you're responsible for how a whole organization builds software, since its four-year rule assumes that kind of history.

The move itself can be internal. An AppSec team that has already seen your reviews and fixes doesn't need a certificate to judge your work. Our AppSec career guide covers the role after the transition, and the product security engineer path covers the version of the job that sits inside a product team.

Our view

We think code you can point to counts for more in this move than in most. We'd put the ASVS write-up and a practical exam ahead of CSSLP for anyone who wants to stay hands-on, and we'd choose OSWE over GWEB if you can give it the time, because a graded exploit says more about a developer than a multiple-choice score. CSSLP earns its place later, once your work is setting policy for other teams. Developers drawn to pipelines and build tooling rather than code review may prefer the DevSecOps path.

Sources