GLOBAL

DEVSECOPS
INSIGHTS
REPORT
2020
The drive to transform
securit y from gatekeeper
to business-enabler in the
world of fast digital
If you only have 5 minutes…

We surveyed and benchmarked 100 organisations, global enterprises and start-

ups, to understand the key challenges they face in embedding security in their agile
development whilst maintaining speed.
Organisations are accelerating through an Agile and DevOps transformation
as they race to move services online quickly through portals and mobile
applications. When a customer interacts with an organisation online, they expect
the experience to be smooth as well as safe. They therefore do not feel the need
to explicitly specify this safety requirement. Companies often sacrifice safety for
functionality and speed, and this has resulted in many high-profile data breaches
worldwide. As a digital company focussing on the future, Capgemini champions and
assists organisations in creating secure digital products in an agile manner, as part of
our global DevSecOps capability.
To understand organisations’ challenges, we surveyed and benchmarked 100
organisations on their DevSecOps maturity. Many of the surveyed organisations
are long-term clients from whom we have gained insights – based on day-to-day
observations, discussions and brainstorming sessions – across a breadth of industries
and locations.
Our survey found that most organisations agreed that delivering secure digital
products quickly should be treated as a business challenge. IT and security alone
cannot solve a business problem, especially when they are subject to constraints
of legacies often found in blue chip companies: legacy technologies, skillsets,
organisational structures, roles, responsibilities, and ways of working. For example, a
central UK government digital delivery centre, with access to some of the best state-
of-the-art technologies the world could offer, found its biggest blocker to achieving
DevSecOps was a deep-rooted, legacy security mindset – as detailed in Part 1 along
with other client insights
Industry Breakdown of Survey Respondents (%) Country Breakdown of Survey Respondents (%)
Industry breakdown of survey respondents (%) Country breakdown of survey respondents (%)
Public Sector, Others 20%
11%
Financial Services,
26%
United States
8%
United
Consumer Kingdom
Products & Spain 7% 54%
Retail, 8% Other, 28%

Energy & France 11%

Utilities, 5%

Manufacturing, 2% Technology, 20%

Figure 1 There was an even distribution of respondents across Figure 2 The majority of respondents were based in the UK
multiple industries

The information contained in this document is proprietary. ©2020 Capgemini Invent. All rights reserved.

2
 Capgemini Invent – Future of Technology

We identified the top three challenges organisations face in DevSecOps transformation

– from both the outset and when scaling up.
Where organisations have automated security tools enabled in their development pipelines,
the top three challenges they face are less technical and more strategic:
• Forming different security practices into design and build frameworks so that they are
standardised and reusable;
• Prioritising which parts of IT or DevOps to transform, the metrics to measure and track
success, and determining when to scale up; and
• Prioritising financial investment – getting the right balance among tools, people and
creating the environment to foster the DevSecOps mindset.
With these key challenges in mind, we share practical ways to turn challenges into
opportunities, in Part 2. We hope you find these tips practical and that they spark a few
ideas of your own. Based on the insights from our extensive client experience and the survey,
we present in this report two key frameworks to approach DevSecOps:
• At a strategic level, through Educate, Automate, Monitor (EAM) principles; and
• At an operational level, through Seven Security Touchpoints in the Software
Development Lifecycle (SDLC).
Security is rarely designed with humans in mind; in fact, the discipline has focused on
keeping humans out of it – out of systems and away from classified information. In Part 3,
we show how we use Design Thinking to kick-start this DevSecOps journey. In a modern
security setting, we want to create frictionless security services that meet the needs of
the business whilst being services that people want to use. We find the Design Thinking
approach to be very useful in co-designing security.
We hope you enjoy the report and if you get even just a few ‘aha moments’, it will make
our long months of interviews and writing all worthwhile. Our DevSecOps benchmarking
database - ‘How secure is your DevOps?’-is also freely accessible on the Capgemini website.

Benjamin Alleau Sandeep Kumar Kay Ng

Managing Director Vice President Senior Manager
Future of Technology Future of Technology Future of Technology

3
 1

DE VSECOPS IS A BUSINE SS
CHALLENGE
In today’s world, pace is everything for businesses to maintain a competitive
advantage. New ways of using technology to bank, travel, shop and consume
media – to name a few – have businesses turning their attention to faster
ways of innovating and responding to customer needs. The role of security
is to enable organisations to achieve this objective in an agile and secure
manner.

4
 Capgemini Invent – Future of Technology

In the traditional world of securing software and system For businesses, this may mean choosing – perhaps unwittingly
development, security teams validate the integrity and – between keeping pace with customer requirements at the
compliance of software and systems at the end of each expense of greater vulnerabilities, and securing products at
sequential phase in the development lifecycle. This includes the expense of high development costs and a lack of speed
final sign-offs and audit trails. As organisations undergo agile to market.
transformation and increasingly adopt DevOps techniques
to thrive in this digital economy, such ‘gated’ security To prevent that from happening, security needs to adopt
assessments have become outdated, and do not fit the Agile a new strategic model ‘Educate, Automate, Monitor’–
model of continuous lifecycle iterations or DevOps approach to educate the workforce, automate security checks,
to removing team siloes. and monitor the IT estate so that security becomes
everyone’s responsibility.

Software Just like Agile transformed the operating model of software

Engineering development and IT operations, ‘DevSecOps’ revamps the
(Dev)
operating model of security. Rather than treating security as
a standalone team and activity, the practice of DevSecOps
embeds security across the software development lifecycle
DevSecOps (SDLC) and aims to make it everybody’s daily job through
self-service or automation. The human side of the story is
IT Operations often missed by organisations, such as the new mindset,
Security (Sec)
(Ops)
skills, roles and responsibilities required of security teams.
One fundamental shift we have observed is the need for
security teams to transform from experts into coaches for
product teams, to help developers design security within new
Figure 3 The three components of DevSecOps features.

Client Insights: The biggest blocker is a deep-rooted

legacy security mindset

In our ongoing work across a number of clients and does not. This causes delays in delivering new customer
industries, we often see widespread educational and features and increased tension between the teams.
cultural issues which end up creating a ‘tug-of-war’ situation
between security and agile product delivery teams. A lack of education causes reluctance to embrace
new and open source technology.
A legacy security mindset creates tension between
teams and destroys value. With limited security experience within delivery teams, and
limited experience of new DevSecOps technologies within
Often, security teams operate in isolation from the rest security teams, security teams are also often reluctant
of the business who are trying to embrace agile ways of to allow delivery teams to use certain technologies,
working but not taking on security responsibilities. This particularly if they are open source and not from a list of
legacy mindset manifests itself in requiring delivery teams approved services and technologies. In our experience,
to complete heavy sets of compliance documentation this list is not updated regularly, or by somebody with a
whenever the design of an application is changed. As good understanding of cloud or related technologies. This
product teams adopt more contemporary architectures (i.e. means delivery teams can often miss out on opportunities
serverless and microservices), the design often changes, to use the latest technology that would ultimately benefit
but the requirement to complete the same documentation the user and organisation.

5
 2

OUR SURVEY REVEALS

THE CHALLENGES AND
OPPORTUNITIES IN
DE VSECOPS
T R A N S F O R M AT I O N
Nearly a hundred organisations have benchmarked their DevSecOps maturity
level using our online survey ‘How secure is your DevOps? 1 over the last year.
The survey is anonymous but provides several insights into the challenges
organisations face when transforming their security capability to keep pace
with agile development.

6
 Capgemini Invent – Future of Technology

Challenge One: Organisations struggle

to embed security in the design and
build stage of software development
Software and application should be built securely by
design. This means applying a security-aware mindset,
attacker stories, blueprints and frameworks to designing
and building features.

When we analysed the results of the benchmarking survey

and compared the top-quartile against the bottom-quartile
organisations, we found the biggest difference between the
two groups to be in design and build – over a 50% difference
– suggesting that this category may be the biggest
contributing factor for overall maturity in DevSecOps.

The main reason, as we have seen in many organisations, is

that to ‘shift security to the very left’ requires revamping
the security operating model.

Top-quartile DevSecOps organisations focus on embedding

security in the design and build stage of agile development.

1.
Available online: capgemini.com/gb-en/service/cybersecurity-services/devsecops-security-in-fast-digital/
7
Revamping the security operating model in itself is a change programme with associated risks, and is often unfamiliar
territory for CISOs. The key areas where change will need to occur include:

Before After

Security-domain focus, e.g. network Product-based focus for security expertise,

Organisation structure security; each domain expert offers e.g. online payment service, offering an
a siloed perspective end-to-end perspective

Limited and formal, through Embedded and informal, through ‘show

Interaction between security,
documentation and periodic formal and tells’ and becoming part of the
IT and business
governance forums e.g. monthly product team

Coach, who educates others to perform

Expert, who performs security
Roles and responsibilities security, automate security work and
assessment and compliance reviews
monitor for exceptions

The right, actionable KPIs and metrics used

KPIs and metrics misused by management,
Continuous improvement by management to drive lessons learned
which drive unconstructive behaviour
and continuous improvement

Table 1 Key areas for change within an organisation

The Opportunity: Security teams Scrum team

should revamp the way they operate

Scrum Master

Scrum team Digital Business Scrum team

and focus on Educate, Automate and Scrum Master

Analyst

UX & Service
Scrum Master

Monitor
Designer
Digital Business Digital Business
Analyst Analyst
Full Stack
Engineer
UX & Service UX & Service
Designer
The most critical thing that security teams need to change is DevOps
Engineer
Designer

their mindset – from how they are going to manage security

Full Stack Full Stack
Engineer Engineer

to how they can enable others to do so. For example, DevOps

Engineer
DevOps
Engineer
instead of ensuring every application has addressed the
Open Web Application Security Project (OWASP) critical
risks, could security teams provide OWASP training to
developers and trust product teams to implement it? As
‘enable’ is an abstract concept, it should be translated into
Educate, Automate, Monitor (EAM) – three verbs that
encapsulate the principles of a new security operating
model:
Pool of security expertise
1. Educate and empower others rather
than policing compliance Figure 4 Adopting an agile squad model means security teams can enable product
teams to develop secure products

Security needs are now too vast and complex for experts
alone to be effective. Security needs to be a team of
evangelists who coach and communicate effectively with
the business and IT to enable shared responsibility for
security. This was never a key skill required from a security
expert previously. Likewise, developers, architects and ops
engineers now need to incorporate security best practice into
everything they do, as the security frontline.

8
 Capgemini Invent – Future of Technology

2. Automate security to help IT and the 3. Monitor exceptions rather than police
business achieve their agility goal non-compliance

There are huge opportunities to automate processes and Compliance to static standards does not mean security –
shift work away from the security team to those working rules and regulations always lag behind innovative attackers.
directly in the software integration/delivery pipeline. Even Instead of periodically checking compliance, actively
security artefacts that cannot be automated should be made monitoring data flows across applications for exceptions
available for fluid self-service, e.g. security requirements can identify actual or potential attacks, vulnerabilities and
catalogues and example attacker stories. instances of secure policy or build breaches. Analysing root
causes allows organisations to fix weaknesses in their security
At a global defence company, Capgemini managed the
models. Application engineers should be included when
modernisation of its application estate as part of a cloud
baselining monitoring, since they know what data is captured,
migration programme. Penetration testing was required
where it is stored and what activity is normal.
for all applications before go live, negatively impacting
time and budget. Working with the development and test For example, below is a threat modelling exercise for a
teams to select the relevant security framework, Capgemini pothole detecting application:
configured static code analysis security rules in Visual
Studio – an application where developers write code – so
that vulnerabilities could instead be spotted during each
sprint and fixed before code was moved to the next stage,
removing future hindrances to IT development and the
business it supports.

Other
organisations
Premium data
(unknown)

2 Automatically detected
when car is moving Database held
by the start-up

Local
Data Potholes data council 1
1 User register

Potholes Data
detection app

User engage with app

3 such as posting
message or pic Potholes data
Local
council 2
Service Developers using
announcement data to enhance
(via email) the app

detected
Figure 5 Instead of ensuring compliance, security teams need to collaborate with application developers on where anomalies could be

9
Client Insights: A Big six energy supplier and an
international car manufacturer shared similar underlying
challenges when ‘shifting security to the left’
We have helped many organisations in embedding security 2. Security is not an integral part of the agile product
in their agile development. A Big six energy supplier was team
accelerating its DevSecOps capability after its initial
focus on Internet of Things agile development had taken In both organisations, there is reluctance amongst
off; while an international car manufacturer needed developers, software architects and project
to uplift its security capability as the business moved stakeholders to embed security professionals within
into car financing and embarked on an ambitious cloud their teams and apply their recommendations.
journey. Two organisations, seemingly in two different Security is still synonymous with delays and additional
sectors, have revealed key factors that trigger resistance work—for example, security may not approve a
to embedding security in the design and build phase of specific user authentication mechanism and insist
software development. on a total re-design rather than simple rectifications.
Often developers end up having additional work
1. Business knowledge gaps in security teams while security professionals are not able to align the
rationale to the agile ways of working and termino
Both organisations found disconnects between
security professionals and the business processes, or 3. Simplicity requires initial complexity
products, they were applying their expertise to. Most
systems today have complex interconnected logical, Tool automation simplifies and accelerates design
procedural, data and technical touchpoints. Only processes, but it also causes discomfort to the delivery
with a holistic understanding of these can security team when adopting it for the first time – even though in
professionals identify and prioritise the spectrum of both cases the clients were operating digital businesses.
vulnerabilities, threat vectors, risks and mitigation Teams need a significant amount of time to identify the
controls needed. This requires rethinking the skill capabilities of each available tool and tailor it for optimised
of the security professional, as well as assistance application to their agile development and business risks.
from the business and product team to create a joint Not all companies have the structure and spirit of ‘early
businesstechnology- security picture. adopters’ who are willing to take on the challenge and
time required for this before tools are used on a large
scale within the organisation.

10
 Capgemini Invent – Future of Technology

Challenge Two: Not using cloud Client Insights: Cloud-

technologies in application
development hampers organisations’ native development
overall DevSecOps maturity teams are more agile
In our survey, we separated the results into two groups:
organisations that use cloud and cloud-based tools in their
application developments (cloud-enabled), and those
that do not. These cloud and cloud-based technologies We worked with a large retail bank adopting Azure
could include cloud infrastructure provided by vendors Infrastructure as a Service (IaaS). Part of the bank – focused
such as AWS, tools that enable continuous integration and on mortgages – moved its operations into Azure IaaS public
deployment of code such as Jenkins. cloud. This reduced the cost of in-house infrastructure
maintenance and allowed the team to reallocate resources
When we compared the two groups’ overall security on developing new features for customers. The use of
maturity level, we found that organisations that use cloud containerisation and microservices improved reliability,
and cloud-based technologies scored a higher level of deployment time and recovery, as incidents only affected
overall security than those that do not. one microservice and not the full application.
Within this new DevOps cloud environment, a successful
On average, cloud-enabled companies outperform non-cloud ‘security-first’ development style was created by forming
enabled companies when it comes to DevSecOps maturity teams where security architects – assisted by guidance
and blueprints from cloud providers – worked alongside
developers in the SDLC. Each team was responsible for a
DevSecOps Maturity Score (%)

70
microservice, which provided clear responsibility lines for
60 maintaining features within the microservice environments.
50
40
30
20
10
0
Cloud-enabled non cloud-enabled
Organisations Organisations

Figure 6 Capgemini DevSecOps survey 2019 – cloud maturity results

Whether cloud-enabled organisations are more secure, or

not, is not a straightforward question to answer. However,
in general in the world of application development, one
key security consideration is applying patches to fix bugs
or patch vulnerabilities. Having a testing environment that
resembles the production environment, and tools that
test the patches automatically, significantly increases the
responsiveness to deploy the patches and the chance of
successful deployment. In a large organisation with over
85,000 employees, a patch could potentially take three to
six months to deploy in an on-premise system. This may even
be longer if the business is averse to allowing downtime to
apply patches.
The agility of cloud, e.g. in deploying patches, makes an
organisation’s Cloud or DevOps teams the best place to
embed security by design.

11
 The Opportunity: Take a ‘lab approach’
to leverage your DevOps to embed
security at the outset, and prove the
DevSecOps business case
During the last wave of agile transformation, organisations
can opt for a ‘lab approach’ in which a Cloud or DevOps
team is set up separately from the rest of the organisation
to serve as a ‘centre of excellence’ until its capabilities
and processes are ready to roll out to the rest of the
organisation. A similar approach could be taken to step up
the Agile or DevOps capability to incorporate security at the
outset – either leveraging the existing centre of excellence
or setting up a separate ‘lab’. In this way it is also possible to
implement and maximise the value of cloud agility.

This approach is most suitable for organisations where the

senior management support for larger change is limited and
there is a need to prove the business case quickly, such as in
the utilities industry where speed was not previously such
a priority. We also adopted this approach in a UK central
government department.

The main benefit of leveraging the Agile operating model

for security is that a lot of the pre-requisites for DevSecOps
are already in place, such as:

- Product-orientated organisation structure – the end-

to-end perspective that a product-based organisation
structure provides is paramount to a risk-based security
strategy. Security decisions made in silos are often out of
context and create blockage downstream that eventually
hurts customers.

- Agile ways of working – security teams can leverage

some agile ways of working to make applications more
secure, such as turning ‘user stories’ into ‘attacker stories’
or using incident data to improve application design.

- DevOps tools – most DevOps tools for automated

testing, such as Jenkins, can be used to automate
security testing based on specified framework (e.g.
OWASP Top 10). Besides ‘shifting security to the left’,
automating security also alleviates security teams’
resource constraints.

This ‘lab approach’ is just one of several approaches, but is

the most common one we have seen when revamping an
organisational operating model.

12
 Capgemini Invent – Future of Technology

Challenge Three: Our data

suggests there is no correlation
between cybersecurity budget and
DevSecOps maturity
By combining Capgemini’s Information Security
Benchmark 2019 report with the DevSecOps survey
results, it’s possible to show there is no clear relationship
between the average spend on cybersecurity versus the
DevSecOps maturity across multiple sectors.
The percentage of IT budget spent on cybersecurity
varies between 3.8% and 7.9%, and that small difference
does not seem to impact how mature an organisation’s
DevSecOps practices are. Indeed, even for Financial
Services, who on average spend more on cybersecurity,
there is no uplift in maturity when compared to
other industries.
This suggests that DevSecOps is not simply something
that can be addressed by purchasing expensive tools.
Tools can only go so far in helping to secure the software
products that are delivered to the end user. To get to
full DevSecOps maturity, organisations need to rethink
their security operating model by focusing on the EAM
principles previously mentioned in Challenge 1.

There is no correlation between cybersecurity budget and

DevSecOps Maturity

Public Sector
Other
Technology
Manufacturing
Energy & Utilities
Consumer Products & Retail
Financial Services

0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 70.00%

DevSecOps maturity % Average % of IT Spend on Cybersecurity

Figure 7 Capgemini DevSecOps survey 2019 – maturity by sector and

cybersecurity budget result

13
The Opportunity: Be strategic with
cybersecurity investment and make use
of open source resources
This lack of correlation between cybersecurity spend
and DevSecOps maturity does not mean tools should
be abandoned altogether. With the rise of open source
technologies and frameworks, organisations unable to
afford expensive enterprise tools can still secure the core
touchpoints of their SDLC – as outlined in Part 3 – for very
little cost. “Examples of these are mapped to each of Seven
Security Touchpoints:”

2 Culture, collaboration 5 Risk based security

and education testing

1 Security blueprint 3 Secure by design 6 End-to-End

and framework monitoring

Security
shifts
Design Build Test Deplpy Monitor
left and starts
here

Attacker stories Agile risk analysis 4 Agile risk analysis 7 Continuous security
improvement

Figure 8 Open Source tools and frameworks to secure the SDLC

14
The below perform the same job as their licensed counterparts. Whilst they may not have on-demand customer service
helpdesks, sleek user interfaces or enterprise-grade features, they offer the chance to implement security practices without
licence or purchase costs.

Security Touchpoint Suggested Open Source Tool/Framework

OWASP Top 10 – Overall Guidance

Security blueprint and framework
OWASP Threat Dragon – Threat modelling

OWASP Security Knowledge Framework – Developer training

Culture, collaboration and education
and guidance

OWASP ZAP – DAST tool

Docker – Container engine
SpotBugs – Java SAST tool
Secure by design
Bandit – Python SAST tool
OWASP Dependency Checker – Open source code vulnerability
checker

Agile risk analysis Moz://a (Mozilla) Rapid Risk Assessment – Methodology

Netflix Chaos Monkey – Application resiliency test tool

Risk-based security testing
Netflix Security Monkey – Cloud security monitoring tool

OpenVAS – Application vulnerability scanner

Risk-based monitoring
NMAP – Network security and auditing tool

Table 2 The security touchpoints and suggested open source tool/framework

Rule of thumb: where

to focus cybersecurity
investment

Small organisations (1-5,000 employees)

– focus on obtaining the right skills

Medium organisations (5,000-25,000 employees)

– focus on establishing the right tools and processes

Large organisations (25,000-50,000 employees)

– focus on cultivating the right culture

15
 Capgemini Invent – Future of Technology

DESIGNING SECURIT Y
S E R V I C E S T H AT T H E
BUSINE SS WANTS TO USE
Every organisation’s culture and SDLC is different, so there is no ‘one-size fits
all’ approach to transform security within DevOps to enable greater business
agility. However, our experience has shown that to succeed in DevSecOps,
to treat it as a business challenge, and to address the three key challenges
highlighted in our survey, you need to put the human at the centre of all
activities, and design processes that reduce security frictions. At Capgemini
we therefore recommend taking a holistic Design Thinking approach to
understand product teams’ pain points in the context of Seven Security
Touchpoints along the SDLC.

16
In software development, there are Seven Key Touchpoints where security can be embedded, which is where organisations
must focus their security efforts to bring the ‘Sec’ into DevOps. These touchpoints are:

2 Culture, collaboration 5 Risk based security

and education testing

1 Security blueprint 3 Secure by design 6 End-to-end

and framework monitoring

Security
shifts
Design Build Test Deploy Monitor
left and starts
here

Attacker stories Agile risk analysis 4 Agile risk analysis 7 Continuous security
improvement

Figure 9 The Seven Security Touchpoints of the SLDC

1. Security blueprint and framework 3. Secure by design

Senior management should ensure that product teams Software should be built securely by design. This means
are provided with an action plan for designing and applying the aforementioned culture, attacker stories,
implementing security policies, controls and education blueprints and frameworks to software design. Code
into the organisation (blueprints) as well as documented reviews, unit testing and dynamic testing should be
information security management policies, procedures targeted according to the attacker stories during design.
and guidance (framework). A set of go-to ‘attacker When this is missed, product teams either don’t consider
stories’ should be considered to support developers’ misuse cases at all, or perform generic testing that creates
user stories by reflecting what malicious actors could do unnecessary work, e.g. to spot false positive alerts from
to compromise product or feature security. When this is automated testing tools. Eventually developers may
missed, the application is often developed in the ‘style’ of bypass automated tools.
the developer, making anomaly detection very challenging.
.
4. Agile risk analysis
2. Culture, collaboration and education
In Agile development, testing occurs continuously,
The mindset, processes, tools, knowledge-sharing and hence risk analysis must also be agile and continuous to
agile relationship between the business, development incorporate test results. Often security teams still use
and IT operations teams needs to enable fast and either a governance tool that is not fit-for-purpose, or
secure software creation, delivery and maintenance. a rigid Excel spreadsheet that quickly escalates out of
Training is provided based on individual roles in the version control. Automated, iterative risk management
organisation and security champions are embedded methodologies and tools, e.g. real-time key risk indicators
into delivery teams. Responsibility for security is shared and Agile risk trees, can improve agility. When this is
beyond the traditional security team. When this is missed or implemented incorrectly, product and security
missed, organisations often see an escalation of tension teams are not able to analyse and capture risk assessments
among teams. from workshops, nor reiterate risk levels in sufficient time
to accommodate new features.

17
 Capgemini Invent – Future of Technology

5. Risk-based testing 7. Continuous security improvement

An automated build and test pipeline – including dynamic Metrics should be identified and used to track
and static application security testing, functional testing improvements and lessons learned from security
and unit testing – should be created based on risk. The incidents, as well as to feed back into the design process
type and extent of testing scenarios should consider and demonstrate the value of DevSecOps. Bug bounty
attacker stories and risk priority. Relevant processes and programmes and Red/Purple teams – who test and
tools based on factors like programming language should enhance security effectiveness using attacker techniques –
be used, and the testing strategy should outline what is are also useful methods to identify areas of improvement.
tested manually or automatically. When this is missed, When this is missed, resources are wasted and teams
product teams can under-test or be overwhelmed with frustrated by repeated mistakes.
false positive alerts.

6. Risk-based monitoring

Monitoring the security status of an application should

always be prioritised. By focusing your monitoring
efforts on the critical components of the application,
e.g. customer databases, you take a risk-based view and
can therefore be more proactive and strategic in your
approach to monitoring. Monitoring can also become
more holistic when you attempt to do the following:
• identify vulnerabilities in code, configurations and
infrastructure;
• detect anomalous security events within your
production and development environments;
• detect drifts from golden image configuration states
and
• detect anomalous movements in application health
metrics.

18
Design Thinking helps uncover pain In the context of DevSecOps, a user may take on the form of
anyone involved in the development of software applications
points in your existing security (e.g. developer, product owner, architect). The service
provider would therefore be anyone who is providing a
processes security service to that user (e.g. central security function).
Mapping out how the user interacts with your security service
Design Thinking is a human-centred and iterative approach in the form of user journeys will enable you to develop a
to creating services that meet the needs of the business, deep understanding of what your user is feeling and where
users and other stakeholders. This approach ensures that the they are encountering friction. Gaining this empathy can help
right problem is being addressed first before committing to a you more clearly articulate the problems in transforming
solution, whether it be technology or process-based. to a DevSecOps way of working, which you can then more
easily resolve using new operating principles and security
touchpoints along the SDLC.
Olivia Blake, Procurement Line Manager, Business Area 1

Olivia has worked as a line manager for 5 years and has a team of 30 people split across two teams. Each team uses 10 apps monthly to perform their tasks.
Recently, her team has seen a change in personnel due to sick leave, re-organisation, new joiners and promotions.

Stages Access request Access request management Access request acceleration

1 6 7 Open physical access 14 19

Receives confirmation from ‘It is easy to find the relevant form to request ‘The helpdesk said they closed ‘Mark has everything now, however,
HR that the person she forms I need to fill in and the building access the ticket as it was not the this was so time consuming! I wish
wanted to hire for her forms are clear, however, it right application, since the there was a central team that
team, Mark, has accepted would be great if I could name we use in the business is manages all the access requests on
the offer and will be submit the request for all 8 different to the name as stated the line manager's behalf. I heard
starting in two weeks.They applications in one form as a in the Request System. Why they have a team like that in
email her his ID number ‘So Mark will need access
lot of information is the to Building A and also would it be different? Now I Business Area B.’
same. 'I wish it was as easy Building B. I know who the need to send a new request,
2 as shopping with Amazon!' approver is for Building A, why can't I just amend it?’
‘I am so glad Mark accepted however, I have no clue
the offer, he will be a great who the approver for 18 Welcomes Mark to the team
addition to the team! I Building B is.’ 13 Calls helpdesk and checks all his access
5
Customer journey

better start requesting all

the access he will need!’ Opens Request System,
fills in multiple application 17
request forms and selects
the approver from the
9 Calls Building B 12
reception to ask for ‘They refuse to process my urgent
drop down menu for each the approver list. ‘It is so easy to see the request request since I do not have a senior
3 application separately progress. Most of the requests enough approver. It is not my fault
Submit request for a have been approved except he is on holiday! Have to wait three
building pass via online 10 request for App X. The ticket
was closed without
days now.’
form 4 ‘They sent me a long list of explanation. I better call the
Submit request for email approvers who I don’t know, helpdesk to clarify why.’
creation and all other ‘This is so annoying! I have
applications on Request to go into three separate I guess I will have to
randomly pick someone!
16 Submits FastTrack form
System systems to request access,
why can’t it be one system?’ Now before I go to lunch,
Submit request for the let me submit the access
third party vendor access request form to the 11 After a week, decides to 15
myself external vendor! check status of her
request on Request System ‘I have received automatic
notifications that all my requests
were approved, just in time for
Mark’s start tomorrow... oh no, I
just realised I forgot to request an
email for him!’

# Pain point R O U
Group Journey touch point
E E
1. Having multiple systems to request access leads to an increase in the 4 4
time needed to submit all requests and this causes frustration when End user 13
trying to remember the process for each system
6 6
13 14 16
Pain points

2. Frustration over the repetitive information input, thus slowing down the Request system
request process
Touch points

8 8 8
3. Accessibility and accuracy of approver details, which leads to frustration Third party 10
of finding the approver information every time and having a wrong vendor
person approving access
10 10 Physical access 7
4. Third party vendor requests are managed locally by the business which team
leads to a lack of an audit trail and can increase the risk of granting
unnecessary access 14 14 HR 1
5. There is not sufficient reasoning for the closure of the ticket, thus the
LM has to contact the helpline to clarify the reason and re-submit the 17 17
request (no option to amend), thus slowing down the process

Legend: Colleague’s emotions

Action Post-It Colleague’s thoughts Journey steps Risk Op Efficiency User Experience
throughout the journey

Figure 10 An example customer journey

19
 Capgemini Invent – Future of Technology

Key takeaways

DevSecOps is a business challenge. Many organisations We combine our expertise in strategy, operating
have undertaken a fundamental shift in their operating models, change management and benefits realisation
model from one designed for functional efficiency to with technical expertise in Cybersecurity to help our
one designed for agility. The role of security is to enable clients succeed in today’s digital world. For more
organisations to achieve this objective in an agile and guidance or content related to DevSecOps, and
secure manner. We believe that using a human-centric information on how to get in touch, please visit our
Design Thinking approach is the best way to create website.
frictionless security services that the business wants to
use. Our two frameworks help in distilling complexities
to manageable actions: at a strategic level through
Educate, Automate, Monitor (EAM) principles; and at an
operational level through Seven Security Touchpoints at
the Software Development Lifecycle (SDLC).

20
For more information about Capgemini and our offer to support organisational
transformation towards DevSecOps, please reach out to our key contacts below.

Global FoT heads contacts at Capgemini Invent

GLOBAL

Benjamin Alleau
benjamin.alleau@capgemini.com

NORTH AMERICA
NORTH AMERICA
Jace Cole
jace.cole@capgemini.com

EUROPE
FRANCE UK DACH
Arnaud Balssa Sandeep Kumar Nora Preisker
arnaud.balssa@capgemini.com sandeep.j.kumar@capgemini.com nora.preisker@capgemini.com

NETHERLAND NORWAY SWEDEN AND

Chantal van Lint Marius Furulund FINLAND
chantal.van.lint@capgemini.com marius.furulund@capgemini.com Ulf Larson
ulf.larson@capgemini.com

SPAIN
Mario Camarero
mario.camarero@capgemini.com

ASIA PACIFIC
INDIA SOUTH EAST ASIA AUSTRALIA
Nidhi Grover Kaustav Roy Stephan Taitz
nidhi.grover@capgemini.com kaustav.x.roy@capgemini.com stephan.taitz@capgemini.com

We would like to thank the following subject matter experts for their contribution to this report:
Charli Douglas, Dan Harrison, Holger Kuprian, Dion Alexopoulos , Kay Ng

21
APPENDIX
Research methodology and survey respondents
This report is based on the information collected from 96 respondents to the DevSecOps Security Assessment between 2018
and 2019. The participants cover a wide range of industries, geographies and roles that have helped gather a representative
sample to provide meaningful and accurate insights.

Industry Breakdown of Survey Respondents (%)

Participant’s industry: The insights in this report were Industry breakdown of survey respondents (%)
generated from organisations across six primary industries. Public Sector,
The industries of a subset of respondents were considered 11%
Financial Services,
too niche to be included in the summary and are therefore 26%
assigned to the ‘Other’ category. The majority of responses
come from the Financial Services (26%), Public Sector (11%)
and Technology (20%) industries.
Consumer
Products &
Retail, 8% Other, 28%

Energy &
Utilities, 5%

Manufacturing, 2% Technology, 20%

Figure 1 There was an even distribution of respondents across multiple industries

Participant’s country of origin: The majority of respondents Country

CountryBreakdown
breakdown of
of Survey Respondents(%)
survey respondents (%)
were based in the United Kingdom (54%), although other
European countries account for a significant proportion Others 20%
of responses, including France (11%) and Spain (7%). There
was a subset of respondents from different countries (20%)
and given the variety of these countries, the respective
United States
respondents were assigned to the ‘Others’ category. 8%
United
Kingdom
Spain 7% 54%

France 11%
Figure 2 The majority of respondents were based in the UK

22
 Capgemini Invent – Future of Technology

Participant’s role: Each of the individual respondents was Respondee

RespondeeRole
role Breakdown (%)
breakdown (%)
asked which role best described them: Technology, Security
Others 8%
or Risk & Compliance. 41% of respondents worked in a
Technology-based role i.e. DevOps. 38% of respondents
Risk &
recognised themselves as working in a Security role i.e. Compliance
practitioner/analyst. Only 13% of respondents felt that Risk 13% Security 38%
& Compliance best described their role i.e. practitioner/
analysts. A remaining 8% of respondents did not feel that
their roles were appropriately described within those
categories, and thus are termed ’Other’.

Technology 41%

Figure 11 The majority of respondents worked in a technology role

23
 ABOUT
CAPGEMINI INVENT
As the digital innovation, consulting and transformation brand of the
Capgemini Group, Capgemini Invent helps CxOs envision and build
what’s next for their organisations. Located in more than 30 offices
and 22 creative studios around the world, its 6,000+ strong team
combines strategy, technology, data science and creative design
with deep industry expertise and insights, to develop the new digital
solutions and business models of the future.

Capgemini Invent is an integral part of Capgemini, a global leader

in consulting, technology services and digital transformation. The
Group is at the forefront of innovation to address the entire breadth
of clients’ opportunities in the evolving world of cloud, digital and
platforms. Building on its strong 50-year+ heritage and deep industry-
specific expertise, Capgemini enables organisations to realise their
business ambitions through an array of services from strategy to
operations. Capgemini is driven by the conviction that the business
value of technology comes from and through people. Today, it is
a multicultural company of 270,000 team members in almost 50
countries. With Altran, the Group reported 2019 combined revenues of
€17billion.

Visit us at

www.capgemini.com/invent

The information contained in this document is proprietary. ©2020 Capgemini Invent.

All rights reserved.