Machine Translated by Google

Licensed for Distribution

This research note is restricted to the personal use of Samuel Braga

([email protected]).

Essential Skills for Security in Modern Application

development
Published 1 December 2021 - ID G00757815 - 36 min read

By William Dupre

Initiatives: Application Development for Technical Professionals and 1 more

Application developers must learn new skills to ensure applications are securely developed
to reduce risk with traditional and DevSecOps delivery. From leadership and architecture to
development and operations, application technical professionals must obtain and cultivate
necessary security skills.

Overview
Key Findings
ÿ
Application vulnerabilities that can be exploited by malicious actors continue to proliferate,
requiring organizations to deliver secure applications using modern development practices.
With the limited number of security engineers available and organizations moving to faster
delivery models like DevSecOps, application developers cannot continue to rely solely on
security teams to ensure the security of applications.

ÿ
DevSecOps processes are providing application developers with more capabilities not only
to deliver code artifacts to various environments, but also to provision resources in those
environments. This is increasing the exposure of developers to operational environments.

ÿ
Understanding the organizational rationale for ensuring secure applications is critical to
navigating a charged political environment. Prioritizing application security often causes
conflicts between groups, while working to secure applications in this environment requires
diplomacy and effective evangelism of application security across the organization.

ÿ
Selecting which security skills and technologies to invest in is difficult for application
developers because of the breadth and depth of the security domain; developers simply do
not have the time and resources to become security experts.
Machine Translated by Google

Recommendations
To develop security skills that reduce risk in deployed applications, application technical
professionals must:

ÿ Acquire and reinforce core skills first, including performing threat modeling, using secure
coding standards, verifying application security and prioritizing vulnerabilities. Also, gain
proficiency in application security processes and technology in the operational environment.

ÿ Prioritize skills that fundamentally improve application security practices, help reduce
business risk and enable other application security skills. These include using secure coding
practices, identifying security requirements, threat modeling and championing security.

ÿ Develop new skills after mastering core skills to keep up with the changing application
security landscape. Focus on skills that align with current and future application
development and security needs, while ensuring that the skill sets continue to be valuable.
Examples include securing the software delivery pipeline and protecting APIs.

ÿ Evangelize application security and promote a culture of learning by joining and initiating
communities of practice, “lunch and learns,” “hackathons,” security sprints, and book clubs.

Skills Analysis
Vulnerabilities in web applications, mobile apps and APIs have become primary attack vectors
malicious actors to breach organizations. web-based
1 Organizations
products,move
it has more
become
quickly
impossible
to deliver
forfor
security engineers alone to verify the security of applications. Application technical professionals
must learn new skills to understand and implement application security.

Organizations need to build and deploy secure applications, especially as they deploy them
to modern, cloud-based infrastructure. To do this effectively in agile environments, application
developers need to learn how to design, develop and deploy applications with security as a
primary focus. Waiting to learn skills until there is a business requirement introduces security
risks, including added pressure to learn and implement skills too quickly. Yet learning the right
skills will critically improve application security, thereby reducing risk to the organization and
creating new career opportunities for developers.
two

The challenge for application developers is that application security has many areas to
consider. Determining which skills to invest in is difficult.
Machine Translated by Google

Which skills do I need to learn to improve the security of applications,

and how do I prioritize them?

This research helps to answer that question by describing and prioritizing the essential
application security skills that developers need to learn to be successful.

Application Security Skills Scope

Determining which security skills are relevant for an application developer is a difficult process.
Developers should use this framework to help answer four key questions:

ÿ How relevant is this skill to the application developer role?

ÿ What is the potential impact of this skill?

ÿ What are the challenges in learning this skill?

ÿ What are the challenges in applying this skill in production systems?

Figure 1 illustrates that breakdown for the top application developer skills with respect to
security.
Machine Translated by Google

Figure 1: Application Development Security Skills Scope

The relevance, impact, learning curve, and impedance position and values shown in Figure
1 are relative to how they affect the application developer and application development as
well as how they improve application security.

Developers should consider the following criteria and questions, also illustrated in the legend in
Figure 1. They should also use these criteria to identify the most appropriate skills to learn.

relevance

Is the skill currently relevant for application security and currently lacking within the
organization? This is represented by the concentric rings. Closeness to the center indicates
more relevance to current application security and, therefore, a higher urgency to learn now.
The relevance positions are:

ÿ Core: This identifies skills that a developer should be using now as long as the skill aligns
with the area of focus and organizational needs. These skills are widely adopted, heavily
used and proven to provide significant benefits. Additionally, these skills benefit from more
mature frameworks, tools and community support. Developers should prioritize core skills
over the others because they are fundamentally valuable in staying relevant as application
security continues to evolve. For example, all developers should be knowledgeable in and
Machine Translated by Google

use the secure coding practices for the language and frameworks being used in their current
development environment.

ÿ Valuable: This identifies skills that have proven valuable and are likely to become a future
core part of secure application development. These skills have reasonable adoption, but are
not fully adopted as core skills. Developers should prioritize these skills based on alignment
with their area of focus as an application developer, the current organizational needs and
their desired future state as a developer.

ÿ Specialized/emerging: This identifies skills that a developer should be aware of and

potentially learn to prepare for future requirements and to get ahead of their peers. These
skills are valuable, but may only be applicable in specialized application use cases or are still
emerging and evolving. Skills that are still emerging have a tendency to be unpredictable and
are therefore unsuitable for applications that require predictability and a slow pace of change.
Developers should understand the evolution of these skills and learn them in order to
recognize specific needs or requirements that they are able to satisfy.

Positive Impact on Application Security

Will the skill improve the security of applications being delivered and is it significantly beneficial
to the organization? This is represented by the shades of color shown next to the skill. The
darker the shade, the higher the positive impact the skill represents. The following topics should
be considered in order to understand the positive impact on application security:

ÿ Security contribution: New skills will help the development of more secure applications. This
forms the strongest impact on application security.

ÿ Security awareness: New skills will help promote a culture of awareness with respect to
application security. This includes awareness across roles within the organization.

ÿ Risk reduction: New skills will reduce the security risks in the deployment of applications.

Learning Curve
How difficult is it to learn the skill? This is represented by the numerical value (1 through 3)
shown next to the skill. The higher the value, the more difficult the learning curve. Also,
developers should apply their existing knowledge as they review the learning curve. For
example, a developer who acts as a mentor and is capable of explaining complex engineering
topics to different organizational roles will be better equipped to evangelize application security
across those roles. Considerations for learning curve include:

ÿ Available resources: Are there experienced peers, coaches, books, online classes, boot
camps, hackathons, communities of practice, vendor documentation, SDKs or sample
projects available? Is there a security engineer available in the organization to provide
support?
Machine Translated by Google

ÿ Prerequisites: Are there technology prerequisites, skills or other requirements needed to be

able to learn this skill?

ÿ Time: Are there difficult-to-grasp concepts, or a large amount of information that must be
absorbed to learn the skill? Is this a skill you can learn as part of your normal work time?

ÿ Required proficiency: How much proficiency is required to effectively gain value from this
skill?

Impedance to Apply
How hard will it be to begin applying the skill in the current application development processes?
This is represented by the points on the shape next to the skill. The more points on the shape,
the heavier the impedance factors to successfully begin applying the skill. Typical impedance
factors include cultural/process shifts, costs, effort and required coordination. All things being
equal, developers should learn skills with a darker shade (positive impact) and few points
(minimal impedance). Also, keep in mind that, even if the skills already exist or the organization
hires for the skills, applying them requires overcoming these impedance factors.

Categories
Is the skill something that fits well in a specific area of focus? This is represented by the four
quadrants described in the following bullet list that break the skills into specific areas of focus.
Note that most of the skills listed have aspects that touch the other quadrants, requiring
developers to acquire skills from multiple quadrants. For example, architecture practices will
influence practices in development and operations quadrants. The four quadrants are:

ÿ Architecture/design practices: Prioritize these skills when the focus is applying security
methods and practices to the architecture and design of the application; for example, using a
threat modeling exercise to uncover common injection vulnerabilities within a system design.
Key skills include: security requirements definition and threat modeling.

ÿ Development and verification practices: Prioritize these skills when the focus is on applying
security methods and practices to the development and verification of an application; for
example, developing and testing input validation for an application request to prevent common
injection attacks. Key skills include: secure coding practices, secure code verification, pipeline
protection, and in-app protection.

ÿ Operations knowledge: Prioritize these skills when the focus is on learning technologies to
mitigate security issues in a production environment. The expectation with these skills is that
developers have knowledge in the particular area in order to support security efforts, not
necessarily implementation skills; for example, identifying web application firewall (WAF) rules
to prevent common injection attacks from reaching an application. Key skills include: data
security, WAF rules and API security and workload protection.

ÿ Leadership skills: Prioritize these skills when the focus is on influencing the organization on
Machine Translated by Google

application security practices and processes; for example, educating product owners on the
risks of not addressing common injection vulnerabilities. Key skills include: champion security
and vulnerability prioritization.

Essential Security Skills for Application Developers

This section describes some of the application security skills that are most relevant for
application developers. It is not comprehensive, but represents the top skills that will help
developers maintain relevance and increase effectiveness with respect to application security.
The following subsections describe the skills and important aspects to consider when
evaluating existing skills and which ones to learn next.

“Most aspects of security can be addressed at multiple places within a

software development life cycle (SDLC), but in general, the earlier in the
SDLC that security is addressed, the less effort and cost is ultimately
required to the same level of security .”

— Mitigating the Risk of Software Vulnerabilities by Adopting a Secure

Software Development Framework (NIST 2020)

Learn the Core Application Security Skills First

The skills in this section represent core skills that are fundamental to application security and
the day-to-day activities of application development. They cut across architecture, development,
operational and leadership domains.

The first skills in this section — secure coding practices, secure code verification, vulnerability
prioritization and threat modeling — are fundamental to application security. These should be
learned first and be the foundation for learning additional skills.

Secure Coding Practices

Developers code, and secure coding practices and standards enable them to develop
applications with fewer vulnerabilities. Such practices have a high impact on application
security because they limit the number and severity of vulnerabilities that escape into
downstream environments. They also ease the burden on development processes by limiting
the number of issues found later in verification tools, thus reducing the time and effort for
rework.
Machine Translated by Google

“Less than 25% of global developers feel that the secure coding
education they're currently receiving is adequate.”

— 2021 DevOps Secure Coding Education Survey — Cyber Security Hub

The Open Web Application Security Project (OWASP) provides a Secure Coding Practices
Quick Reference Guide. Some of these practices include:

ÿ Input validation

ÿ Output escaping and encoding

ÿ Access control

ÿ Session and file management

ÿ Data protection

ÿ Error handling and logging

ÿ Database security

Other frameworks to consider include the Microsoft SDL, the NIST Secure Software
Development Framework and the OWASP Mobile Security Project.

Any set of organizational coding practices must also account for the specific features and
controls of the various languages and platforms being used. For example, mobile application
development practices must take into account the use of secure storage areas (eg, iCloud
Keychain) and the setting of appropriate application permissions (eg, Android manifest files).
Web APIs often carry enough uniqueness that they deserve their own sets of practices. For
details on platform-/framework-specific coding practices, see A Guidance Framework for
Establishing and Maturing an Application Security Program.

Depending on the industry, an application security program may have to account for specific
regulations. Financial Industry Regulatory Authority (FINRA), Health Insurance Portability and
Accountability Act (HIPAA), General Data Protection Regulation (GDPR) and Payment Card
Industry Data Security Standard (PCI DSS) all include requirements for securing systems and/
or data. These regulations may have specific requirements for secure coding practices, which
must be understood by developers. As an example, PCI DSS requires the use of secure coding
guidelines with some requirements calling out the OWASP Top 10 web application security
risks for developer guidance.
Machine Translated by Google

Along with these practices, developers should be skilled at writing security-focused unit tests.
These tests should be used to verify that proper controls are in place for techniques like input
validation and output encoding, but should also be used as regression tests against security
findings from other testing practices (eg, penetration tests).

DevSecOps — a modern approach to software development that relies on automation to enable

collaboration between development, security and operations teams — is another practice in
which developers should be skilled. While application security should be a common practice for
any development process, DevSecOps typically requires that application developers take more
responsibility for the security of applications. This added responsibility includes some of the
techniques mentioned in this research. With this skill, developers need to better understand the
various techniques for automation and collaboration.

Secure Code Verification

Secure code verification consists of practices that include application security testing (AST)
and secure code reviews. These efforts have a high positive impact on application security
because they provide insight into application vulnerabilities and unsecure coding practices
early on in development processes.

There are three main styles of AST that developers should learn:

ÿ Static AST (SAST): Technology that contains an application's source code, bytecode or
binary code for security vulnerabilities, typically in the development and/or testing phases.

ÿ Dynamic AST (DAST): Technology that applications in their dynamic, running state during
testing or operational phases. DAST simulates attacks an application (typically web
applications and APIs), against the application's reactions and thus, identifies any possible
vulnerabilities.

ÿ Interactive AST (IAST): Technology that identifies vulnerabilities during normal testing
practices by blending static and dynamic analysis techniques through instrumentation of the
running code.

Along with the above testing styles, developers must learn to use software composition
analysis (SCA) technology, which identifies open-source and third-party components in use in
an application, along with their known security vulnerabilities. Third-party components make up
3 and can
about 70% of modern applications Gaining be theand
visibility source of most
enabling vulnerabilities
developers found.these
to address 4
issues early in the development process are imperative to improving application security.

Developers should be skilled at analyzing the output from these various tools and be able to
remediate the identified issues. It is preferable that developers be skilled at using integrated
development environment (IDE) plug-ins for some of these tools (eg, SAST and SCA) so that
the issues can be identified and addressed before code is committed to a central repository.
Machine Translated by Google

Figure 2 shows a typical software build pipeline and where AST and SCA scanning usually
takes place.

Figure 2: Integrating Security Testing Into the CI/CD Build Pipeline

Developers should also be skilled in reviewing code for possible security issues, including
coding standards violations and design flaws. Such reviews help identify weaknesses and
vulnerabilities within code and create learning opportunities across development staff. To
support the review process, developers should use secure coding standards (both internal to
the organization and platform-/framework-dependent), automated review tools, threat models
and output from AST tools. 5

These practices can also be explored in the following research:

ÿ A Guidance Framework for Establishing and Maturing an Application Security Program

ÿ Guide to Application Security Concepts

Machine Translated by Google

All of these practices together require an intermediate level of learning for developers. Being
proficient in the different AST/SCA tools and what their individual focuses are and prioritizing
their findings require training. Secure code review skills, however, should require less effort if
developers are already skilled in general code review practices and relevant tooling.

Vulnerability Prioritization

An application security verification process (as described in the Secure Code Verification
section) is one source for identifying vulnerabilities within applications. However, organizations
may also have vulnerability management (VM) processes that identify issues in third-party
libraries, external services and frameworks that are used within applications. Also, the penetration
testing program may regularly identify vulnerabilities within applications. All of these possible
application-impacting vulnerabilities must be prioritized appropriately in order to be remediated
within the SDLC process.

Prioritization is necessary because security verification and VM processes can identify many
issues within applications, not all of which can be addressed within a timely manner.
Developers must balance their time between developing business features and addressing
various categories of defects, including security vulnerabilities. Effective prioritization can
balance these trade-offs while having a positive impact on limiting organizational risk.

Developers should already be skilled at defect prioritization, so adding vulnerabilities to the

prioritization process should require only a moderate impedance to apply. However, learning
how to effectively score a security vulnerability can be difficult. Some areas in which
developers must be skilled or understand to effectively prioritize vulnerabilities include:

ÿ CVEs and CWE standards: Common vulnerabilities and exposures (CVEs) and common
weakness enumeration (CWE) are community standards for identifying vulnerabilities and
software weaknesses. The CVE provides a reference to a publicly known vulnerability in
software (including open-source components) and is assigned a unique identifier and
severity. CWEs are a list of software and hardware weaknesses types. The various tools
identifying application vulnerabilities will use these standards to reference found issues.
Developers must have some understanding of these standards in order to investigate the
risk of a discovered vulnerability.

ÿ Vulnerability scoring: Security verification and VM tools typically score vulnerabilities based
upon some industry or product standard, eg, the Common Vulnerability Scoring System
(CVSS). Understanding these scores and knowing when and how they can be adjusted
require some knowledge of specific vulnerabilities, where they exist within the application,
ease of exploitation, what data might be impacted and if they are mitigated by other means.

ÿ Cross-team collaboration: An important aspect of prioritization is the application

developer's ability to collaborate with the security team. Security engineers are in a better
position to understand the security impacts of specific vulnerabilities. However, security
teams are not sufficiently staffed to address daily vulnerability findings. Developers must
Machine Translated by Google

use security teams as coaches in learning appropriate prioritization for vulnerabilities.

ÿ Risk tolerance: Not all identified vulnerabilities can be resolved in a manner consistent with
reducing risk. Developers must understand when risk from not remediating a vulnerability
can be tolerated. However, whether or not to accept the risk should not be a decision left
solely to developers — it must be a collaborative effort with security and business, informed
by the risk tolerance of the organization.

Threat Modeling

Threat modeling is a form of risk assessment that attempts to identify threats against and
weaknesses in a system. The primary goals of threat modeling are to:

ÿ
Understand the relevant system components as well as user and machine interactions with
the system (or systems)

ÿ Identify weaknesses in the design and any associated risks

ÿ Determine the appropriate countermeasures and mitigations

In the 2021 OWASP Top 10 Web Application Security Risks, unsecure design debuts at No. 4. It
states, unsecure design “focuses on risks related to design and architectural flaws, with a call for
more use of threat modeling, secure design patterns and reference architectures.”

Application developers must learn this skill in order to apply it during the design phase of the
development process. There is a high-positive impact if this task is performed early in the SDLC
because it allows for a vulnerable design to be addressed quickly before it becomes realized
during implementation. However, there is also a benefit in using a threat model to understand and
improve an existing implementation. In addition, threat modeling has a positive impact on
collaboration since most exercises require input from security, operations, and development
teams.

“Threat modeling should be done multiple times during development,

especially when developing new capabilities, to capture new threats and
improve modeling.”

— Guidelines on Minimum Standards for Developer Verification of

Software (NIST — 2021)

Table 1 provides a list of some standard threat modeling methodologies. Application

Machine Translated by Google

developers should understand the concepts and purpose of threat modeling and be able to use
at least one of these methodologies proficiently. Which methodology to use will depend on
personal preference, organizational/product/project need and current industry trends.

Table 1: Threat Modeling Methodologies

Methodology Description

attack trees Models attack in a tree form with the root of the tree being the goal of
the attack. Typically used with other methodologies.

DREAD Used to classify risk based on damage potential, reproducibility,

exploitability, affected users and discoverability.

LINDDUN Used to identify and mitigate privacy threats in software systems.

MITER ATT&CK A knowledge base of adversary attacks and techniques. used as a

framework for threat modeling, penetration testing and defense
development.

OCTAVE Used to identify and assess risks to IT assets. It assesses organizational

risks, not technological risks.

FOLDER The seven-stage, risk-centric threat modeling framework to identify threat

patterns against an application or system.

STRIDE Used to classify threats based on the categories of spoofing identity,

tampering with data, repudiation, information disclosure, denial of
service and elevation of privilege.

trike Used for security auditing processes to identify whether an assigned

level of risk is “acceptable” for an asset.

Source: Gartner (November 2021)

To learn threat modeling, application developers should work with security teams to
Machine Translated by Google

understand the typical and current threats to applications. There are also gamification
exercises that help teams learn threat modeling techniques (eg, Microsoft's Elevation of
Privilege and OWASP Cornucopia), as well as tools that facilitate the process. Initially, threat
modeling can be an informal exercise for developers as they learn the techniques and
processes. All of these approaches increase the ability of developers to learn threat modeling
while reducing the overall impedance of the practice.

Security Requirements Definition

In modern development processes, like DevSecOps, developers are typically part of a team that
creates requirements for application features. While business analysts write requirements for
business functionality, developers provide input and requirements for features such as
maintainability, reusability, testability and resilience. Security requirements typically come from
security professionals, but developers must take on this responsibility with collaboration from
security teams. In the end, though, security requirements must be treated just like functional and
other nonfunctional requirements and be just as visible to development teams.

“Security requirements should be defined and analyzed for each and

every stage of application's life cycle, adequately addressed and
managed on a continuous basis.”

— ISO 27034-1 Section 0.4.1 — Security is a requirement

Some security requirements will be considered acceptance criteria in a business user story. For
example, a user story that requests functionality to accept user input, should contain acceptance
criteria requiring that the input be properly validated and sanitized before being processed. This
can help prevent security issues like injection vulnerabilities. Other security requirements may
need to be user stories themselves. Also, developers should help define abuse cases; that is,
specifications “of a type of complete interaction between a system and one or more actors, where
the results of the interaction are harmful to the system, one of the actors, or one of the
6
stakeholders in the system.”

Developers should be skilled in providing acceptance criteria and user stories to address
security requirements. The OWASP Application Security Verification Standard provides
guidance on specific security requirements that you need to be considered during the design
and development of applications. Examples include requirements for input validation and
output encoding, authentication controls, and data protection requirements.

As mentioned above in the Secure Coding Practices section, organizations falling under certain
regulatory authorities (eg, FINRA, HIPAA, GDPR, PCI DSS) may be required to implement
Machine Translated by Google

specific protections for systems and data. Developers must know when and how to design
application requirements to support these compliance policies.

More information on security requirements can be found in A Guidance Framework for

Establishing and Maturing an Application Security Program.

Data Security

1 shows
the The Verizon 2021 Data Breach Investigations Report resultthat 39%application
of web of all breaches were
attacks.
These breaches included unauthorized access to application and other organizational data.
Application developers must understand how data can be exfiltrated and how it is protected in
a production environment in order to influence development processes and incident response
practices.

As developers use techniques such as infrastructure as code (IaC), they must take into account
security controls for the infrastructure they will be provisioning. For instance, when provisioning
a database instance, that database may need to be encrypted. Also, cloud storage systems may
need to have restrictive configurations applied so as not to be exposed publicly.
Unfortunately, misconfigurations of such data assets have become a growing problem for the
confidentiality of an organization's data.

In light of these problems, developers must understand some of the following controls in order
to secure data properly:

ÿ
Transparent data encryption (TDE): File-level encryption for databases, protecting data at
rest. TDE does not protect data in transit or in use.

ÿ
Secure data transport: Encrypting data in transit, typically with transport layer security (TLS)
— the standard security protocol for web applications and APIs.

ÿ
File encryption: Encrypting individual files or folders on a server that need to be protected
from unauthorized user access.

ÿ
Key and secret management: Managing keys and secrets to maintain security and
availability, especially for data-at-rest encryption and API integration.

ÿ Cloud storage security: Configuring cloud storage services to prevent unauthorized access.

For details on these concepts, see Guide to Data Security Concepts and Building the
Foundations for Basic Security Hygiene.
Machine Translated by Google

With the power given to DevSecOps teams through infrastructure as

code comes great risk and responsibility.

In a DevSecOps environment, security and operations teams should apply specific controls that
confine developers to secure resource provisioning. Such controls, or “guardrails,” identify when
infrastructure has been provisioned in a way that violates security policies, along with possible
remediation actions.

Champion Security

The reality for most organizations is that an application security team, if one exists, will never
be large enough to support all applications and application development in the enterprise. A
decentralized approach with delegation of some responsibilities is almost always required to
ensure application security work is completed appropriately. This is where developers, acting
as security champions, can provide a high positive impact on application security.

Security champions should have a good balance of technical aptitude, soft skills and project
management proficiency so that they can communicate within their teams and complete
security tasks. They will also need to be key points of contact for security teams in order to
deliver on and monitor security requirements.

Along with the skills identified elsewhere in this research, developers will need some of the
following capabilities to champion security:

ÿ Openness to being a security champion: Organizations shouldn't try to force a developer to

become a security champion. The activity should be something that aligns with the
developer's own goals, willingness to learn and level of aptitude. Just adding another
responsibility onto a developer's plate doesn't create a good incentive for that individual to
champion security.

ÿ Security evangelism: To be an effective security champion, a developer needs to be able to

communicate the importance of security concepts and tasks to various roles in the team,
including project and product leadership. The developer should also be proactive in this
communication to promote security awareness among the team.

ÿ Political navigation: Advocating for application security support can be challenging. It will
require diplomacy and tact to navigate the politics that comes about when prioritizing
application development tasks. It is the role of the security champion to socialize application
security within the team and appropriately communicate risk. Being able to do so logically
and factually will be important to reducing the perception of security being an inhibitor of
product delivery.
Machine Translated by Google

The learning curve to acquire these skills is steep. Some skills will require training and
guidance, while others will require developers to establish leadership capabilities. However,
being a security champion should not be looked upon as an all or nothing skill. Many
champions' programs are tiered and award individuals based upon levels of attainment. One
example is a progressive model using belts based loosely on Brazilian jiujitsu. Figure 3 shows
an example of this model.

Figure 3: Example Security Champion Progression

One form of training for security champions is gamification as mentioned in the Threat
Modeling section. For more on security champions and gamification, see A Guidance
Framework for Establishing and Maturing an Application Security Program.

“We are also beginning to see some organizations use satellite (security
champion) members to bootstrap the 'sec' functions they require for
Machine Translated by Google

transforming a given product team from DevOps to DevSecOps.”

— Building Security In Maturity Model (BSIMM) version 11

A developer as a security champion has a high positive impact on application security because
it ensures that there is a voice of security in the development team. This is an imperative for
reducing organizational risk due to the quick pace of development in DevSecOps processes
and the typical lack of dedicated application security personnel.

Learn These Valuable Application Security Skills Soon

This section describes capabilities that application developers should become acquainted with
as soon as possible. Developers should begin learning these skills, at least at a basic level, so
that they are familiar with the security benefits and challenges each represents as well as where
they are applicable in current and future applications. Developers should become proficient in
and apply these skills when they recognize the clear value within their organization.

Pipeline Protection

As important as it is to protect the development artifacts going through the continuous

integration pipeline, it is just as important to protect the pipeline itself. Software supply chain
attacks are a growing problem, with malicious actors exploiting weaknesses at every stage in
the software procurement, development and delivery life cycle. This includes everything from
injecting malicious code into application artifacts to installing back doors in third-party software.
Application developers must be ready to adapt to pipeline security controls as they become
standard within organizations.

Code going through an unsecured continuous integration pipeline is not

secure.

Listed below are some of the pipeline security controls for which developers should acquire
skills. Compliance with these practices will be dependent upon whether the organization has
these controls in place.

ÿ Strong source code control policies (see Table 2)

ÿ Trusted component registries

ÿ Secured continuous integration environments

Machine Translated by Google

Table 2: Strong Source Code Repository Policies

policy Control Developer Adaptation

Enforce access ÿ granular role-based ÿ Use multifactor authentication

policy controls permission levels techniques where available

ÿ multifactor
authentication

Enforce branch ÿ Require signed ÿ Sign commits to the source code

protection rules commits to repository repository (eg, using GPG in Git)

ÿ Prevent forced push to ÿ Do not force push to a repository

repository Understand what checks are
ÿ

ÿ Require status checks being applied during commits

before commits

Prevent the ÿ Precommit hooks to ÿ Don't hard-code sensitive data in

committing of block sensitive data code artifacts

secrets
ÿ Scan for secrets ÿ Conduct peer reviews on code to look for
hard-coded sensitive
ÿ Mandate code reviews
date

Source: Gartner (November 2021)

Application developers must use trusted components to build their applications. This process
includes pulling artifacts from approved repositories, using approved container registries and
using SCA tools (as mentioned in the Secure Code Verification section). Many organizations
use local repositories and registries that are managed for compliant components.
Development and security teams must work together to make sure these sources have the
necessary and compliant components available for application build processes.

Continuous integration environments are made up of various infrastructure components that

can be on-premises servers and/or cloud-based SaaS solutions. Regardless of where the
infrastructure resides, its components must be secured and hardened to prevent unapproved
access and running with unnecessary privileges. For developers, this means understanding and
adapting to least-privilege access policies and relying on automated processes to perform
Machine Translated by Google

common tasks (eg, artifact deployment).

For more information on these topics, see Using Cloud-Native 'Policy as Code' to Secure
Deployments at Scale, How Software Engineering Leaders Can Mitigate Software Supply Chain
Security Risks and Guide to Application Security Concepts.

WAF Rules and API Security

Modern application and data integration designs make heavy use of web APIs. They are the
backbone of web and mobile applications, with cloud and container deployments, Internet of
Things (IoT) platforms, and microservices architectures also accelerating their development.
This has driven API development to become a core skill for application developers (see
Essential Skills for Modern Application Development). Along with this growth, organizations
7 It isthat
have seen a tripling of attacks against their APIs in recent years. then, of high importance,
developers
understand how APIs are secured in a production environment.

Regardless of whether an application is designed as a set of APIs or a standard web

application, the primary component of application protection is a web application firewall. A WAF
web application or API traffic using a configurable set of rules and can drop or filter requests that
appear malicious. A WAF is typically configured to identify, at a minimum, OWASP Top 10
vulnerabilities such as SQL injection, cross-site scripting (XSS), command injection and path
traversal.

WAFs and API gateways are just baseline technology that is needed for
application security and should not be considered as complete solutions.
Other technologies are emerging that provide behavioral analysis, bot
detection and API discovery. All of these technologies are components
of web application and API protection (WAAP) solutions.

Another component of API protection is the use of API gateway technology. This technology
can come in the following forms:

ÿ Enterprise API Gateway: Typically at the network perimeter to secure inbound and outbound
API traffic.

ÿ Microgateway: A lightweight gateway with a small footprint designed to be distributed and

deployed close to individual services.

ÿ Ingress Gateway: Part of an organization's container environment. It is a component that

functions as the network communications gatekeeper of a container orchestration cluster or
Machine Translated by Google

service mesh.

ÿ Service Mesh: Mediates interservice (east-west) communication within an application

domain.

For more information, see Decision Point for Mediating API and Microservices Communication.

Both WAF and API gateway technology are important security controls that sit between end
users and application functionality. API gateways can also provide application developers
with better visibility into the API inventory within an environment. Figure 4 provides a common
picture of this architecture.

Figure 4: WAF and API Gateway Architecture

Explore These Specialized and Emerging Application Security Skills

The skills described in this section are emerging or are highly specialized and can provide
differentiated value to application security. Developers should watch these skills closely, review
use cases relevant to business needs and look for opportunities to apply them in future projects.

Workload Protection
Machine Translated by Google

Modern applications are being deployed into cloud and container environments. To protect
these environments, organizations are utilizing container-focused cloud workload protection
platforms (CWPPs) — solutions that include build-time, delivery-time and runtime security
features to verify and protect workloads throughout their life cycle. These capabilities span
from system integrity, memory protection, application and network controls to behavioral
monitoring, intrusion prevention and anti-malware protection. Figure 5 illustrates the simple
architecture for a CWPP production deployment.

Figure 5: CWPP Deployment

Another component of workload protection is runtime application self-protection (RASP). This is

technology that instruments code to gain visibility via embedded libraries (ie, SDKs) or agents
in the application runtime environment. RASP offers high-accuracy attack mitigation, especially
for injection-type attacks, by having deep visibility into the application stack.

For more information on these technologies, see Solution Criteria for Container-Focused Cloud
Workload Protection Platforms.

Application developers that understand these technologies are better able to assist in incident
response efforts and secure application design. It is their knowledge of the application stack
and data flow, for instance, that can best assist in interpreting RASP alerts. This has a significant
positive impact for the organization. Learning these technologies, however, can be
Machine Translated by Google

difficult, especially in the area of CWPP, due to the changing vendor landscape and complexity
of container environments.

In-App Protection

In-app protection refers to self-defense capabilities in client-side applications, typically mobile

apps. It includes application shielding and hardening, anti-tampering and anti-malware
techniques. Application developers building mobile apps must use these techniques to secure
their products. Developers may not need to implement all of these solutions because some
pertain to operational controls. However, developers should understand the complete security
environment in which their apps operate.

Table 3 illustrates some of the different in-app protections with which developers should be
familiar. For details on these controls, see Market Guide for In-App Protection.

Table 3: In-App Protection Capabilities

hardening Anti-Tampering Others

ÿ Code obfuscation ÿ Debugger and emulation ÿ Anti-bot detection

detection
ÿ white box ÿ Clickjacking detection
cryptography ÿ Privilege escalation detection
ÿ RASP
ÿ Certificate pinning ÿ Integrity checks multifactor
ÿ

ÿ Resource encryption ÿ Fingerprinting authentication

ÿ Autoexpiry ÿ Malware detection ÿ Risk analysis

ÿ stand alone

keyboard

ÿ Polymorphism

ÿ Removal of test data

Source: Gartner

This skill will have a difficult learning curve and heavy impedance to apply due to the many
different techniques involved. However, developers along with organizations should determine
which specific techniques align best with their goals and environments. This analysis can help
limit the learning and impedance curves. The benefit, though, is significant because protecting
the integrity of an organization's mobile apps helps protect back-end processes and data, as
Machine Translated by Google

as well as the organization's brand.

Recommendations for Building Application Security Skills

Effective application developers do not wait for external factors to drive the evolution of their skills.
Instead, they proactively seek out, identify and learn skills that will improve their ability to deliver secure
applications while still fitting within their time and effort constraints. These skills improve application
security as well as the development process while increasing the relevance of the developer.

Application developers should consider the following recommendations as they begin applying the
principle of continuous learning in application security:

ÿ Start with learning the core skills: The skills identified as “core” in this research are
foundational and will satisfy the security needs of the majority of today's applications.
Additionally, they provide the building blocks to more efficiently learn additional skill sets.

ÿ Prioritize skills that have the highest positive impact on reducing risk within the
organization: Developers should focus on skills that can quickly and effectively improve the
application security of the product they are developing. This will include some of the skills listed in
the Core Skills section. Enlisting help from internal security experts will be imperative to understand
which skills have the highest impact for an organization.

ÿ Adopt skills using the three E's: The three E's are education, experimentation and execution.
This approach enables developers to get experience and apply it correctly. Developers should
enlist others to share experiences, relay best practices and promote a culture of learning
through communities of practice and security sprints.

ÿ Prioritize skills with the highest positive-impact-to-impedance ratio: These skills are essentially
the low-hanging fruit to get the greatest effect in an organization. Developers will need to determine
what it will take to overcome the skill's impedance factors based upon their own current skill set and
the culture within their particular organization.

ÿ Learn with others: Developers should look for opportunities to learn with other developers in their
organization or even in external groups and meetups. They should also look for guidance from
security engineers to help them understand some of the concepts mentioned in this research.
Learning with others provides an opportunity to share code, experiences, tool configurations, lessons
learned, resources and quick-start tips.

ÿ Prioritize skills that can be learned on the job: Developers should look for opportunities to work on
projects with other developers who have expertise in application security skills.
Working with others as part of a production application is a major advantage over learning skills
alone. Also, developers should seek out internal security engineers to help with learning the
security concepts and controls needed for secure application development.

ÿ Enlist the help of management: Management can provide opportunities for learning by
Machine Translated by Google

sponsoring activities such as hackathons, developer days, security sprints, book clubs,
lunch-and-learn sessions and online training.

ÿ Promote a culture of learning: Developers should bring in security and nonsecurity

technologists to help learn key skills. They should start or support communities of practice
where application security professionals can share skills, lessons learned, tools, configurations
and other valuable experience. They should encourage secure practices throughout the
application development life cycle and use this to build relationships with key stakeholders.
These will include people and teams on both the business and IT sides of the organization. For
more information about communities of practice, see How to Build Successful Communities of
Practice for Knowledge Management.

ÿ Look for quick-start guides, tutorials and sample apps: As developers begin to learn, they
should look for resources from technology vendors or online training that help them quickly
become familiar with what is involved in learning the skill. One example would be the OWASP
WebGoat project that helps developers understand security vulnerabilities in Java applications.
Heavy documentation and SDKs are better-used as long-term resources once a developer
already has some level of proficiency and understanding of the skill.

ÿ Own application security: With web applications and APIs being a primary target for
malicious actors, application security skills must be considered a core capability for
application developers. Security of applications is no longer a siloed activity for security
engineers. Application technical professionals must take ownership of the security of their
products.

Evidence

1 2021 Data Breach Investigations Report, Verizon.

two
DevOps Secure Coding Education Infographic, Cyber Security Hub.

3 2021 Open Source Security and Risk Analysis Report, Synopsys.

4 State of Software Security v11, veracode.

5
Home page, We Hack Purple.

6
Using Abuse Case Models for Security Requirements Analysis, James Madison University
(JMU).

7 API Security Trends, Salt Security.

Recommended by the Author

Essential Skills for Modern Application Development
Machine Translated by Google

A Guidance Framework for Establishing and Maturing an Application Security Program

Structuring Application Security Tools and Practices for DevOps and DevSecOps

Solution Path for Continuous Delivery With DevOps

Solution Criteria for Container-Focused Cloud Workload Protection Platforms

Recommended For You

Essential Skills for QA Engineers

2022 Planning Guide for Application Development

Community of Practice Essentials

Assembling an Open-Source App Stack

Infographic: Essential Skills for Agile Development

Recommended Multimedia

VIDEO

Dev vs. Ops — How Trust Was Destroyed

01:15

VIDEO

What Are the Attributes of an Agile Superhero?

03:32

VIDEO

What Techniques Will Help Us Learn Application Architecture and

03:49 Development Skills?

VIDEO

Executive Summary Video: Data Loss Prevention: Comparing

03:19 Architecture Options

VIDEO

Mobile App Architecture Introduction

06:37

Supporting Initiatives
Application Development for Technical Professionals

follow
Machine Translated by Google

Security Technology and Infrastructure for Technical Professionals

Following

© 2022 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. and its
affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior written permission. It
consists of the opinions of Gartner's research organization, which should not be constructed the statements of fact. While
the information contained in this publication has been obtained from sources believed to be reliable, Gartner disclaims all
warranties as to the accuracy, completeness or adequacy of such information. Although Gartner research may address
legal and financial issues, Gartner does not provide legal or investment advice and its research should not be constructed
or used as such. Your access and use of this publication are governed by Gartner's Usage Policy. Gartner prides itself on
its reputation for independence and objectivity. Its research is produced independently by its research organization without
input or influence from any third party. For further information, see "Guiding Principles on Independence and Objectivity."

About Gartner Careers Newsroom Policies Privacy Policy Contact Us Site Index help

Get the App

© 2022 Gartner, Inc. and/or its affiliates. All rights reserved.