The implementation of DevSecOps in your organization,
in a nutshell,
requires a radical transformation in the ways of thinking and acting
concerning security
and how it is integrated into the software development
and delivery processes.
Before going into detail about the principles,
challenges and recommended techniques or practices
for this implementation,
let’s briefly define the DevSecOps concept,
about which we have already presented a more extensive introduction
in a previous post.

What is the DevSecOps methodology?

When we talk about DevSecOps,
we refer not only to a methodology
but to an expanding culture among technology development companies
where security is introduced and addressed from the beginning
to remain throughout the software development lifecycle (SDLC).
In DevSecOps,
as part of an evolution of the prior model
(DevOps),
the security team is integrated into a collaboration
between the development and operations teams.
DevOps was focused on achieving a high speed of delivering
an excellent quality product
to the market.
Now,
DevSecOps retains that goal
but adds the purpose of making sure
that the product is secure.
With this corporate culture,
security becomes a shared responsibility of all organization members.

DevSecOps implementation overview

To implement DevSecOps is to shift security to the left.
It is to integrate it into the technology development process
before the first line of code appears.
To adopt DevSecOps is to bring into the SDLC
security requirements and tests,
vulnerability prioritization and remediation,
and judicious monitoring for risk prevention and cost savings.
Unlike previous methodologies,
the identification and remediation of security problems occur in time
with the development activity,
without waiting until the end of each cycle.
In DevSecOps,
security acts in the software planning,
design, construction, testing and release,
providing continuous feedback to all committed teams.

DevSecOps fundamental components

The implementation of DevSecOps is based on four fundamental components:
people, processes,
technologies and governance.

First,
it is the people,
i.e., the team members,
who will be integrated to cooperate.
They are who,
as part of the cultural change,
will assume shared responsibility for security in their workflows.
They are who will train and be trained
so that security is injected into the corporate DNA.

On the processes side,
the shared responsibility model requires that
the overall goals of software speed,
security and stability are maintained by all stakeholders.
Therefore,
best practices in security,
development and operations must be embraced
from the outset and across the entire SDLC.

For the above,
the support provided by technologies is crucial.
These are integrated into the cycles
and facilitate many processes.
Security testing with automated tools,
for instance,
that complement manual security testing by experts,
is valuable in the DevSecOps culture.
However,
automation must be used when necessary and not excessively
so that it doesn’t affect the effectiveness of software development
and deployment.

Finally,
DevSecOps must involve governance.
Companies must monitor their procedures,
measure their performance,
identify and analyze their obstacles,
failures and progress,
define challenges
and learn and improve with the help of feedback.
The metrics obtained
throughout the organization’s DevSecOps maturation
are pretty helpful for governance decision-making.

DevSecOps principles or basic steps

Relative to these elements,
the following are some principles or basic steps
in the implementation of DevSecOps
within an organization:

• Foster a gradual cultural change.

• Educate, train and certify staff in various roles in security
  and best practices.

• Choose at which points in the SDLC
  to carry out specific security procedures.

• Automate processes
  (including some of the governance)
  and tools for stability and repetition
  in different phases of the cycles.

• Start by evaluating small portions of code
  or specific, prioritized cases.

• Conduct continuous manual interventions
  to retest and drill down.

• Use metrics to measure performance and progress,
  and learn from feedback.

DevSecOps adoption drivers

The popularity of the DevOps methodology has been growing in recent years
because of the agility it brings to software development and delivery.
In the case of the DevSecOps methodology,
its growing popularity is due to its clever
—incredibly not yet seen as necessary by some—
inclusion of security in the preceding approach
without negatively affecting its efficiency.
It was prudent to respond to the security issues
emerging in the accelerated delivery of technology.
Fortunately,
an increasing number of organizations perceive security as a necessity
in an environment plagued by unscrupulous people
who wish to take advantage of human ignorance and errors
by different methods and paths.

DevSecOps is attractive
because it allows the constant prevention of risks
and mitigation of threats
that undoubtedly arise in software development.
Also,
because the early detection of vulnerabilities enables their remediation
before going to production
and at much lower costs.
Thanks to the DevSecOps implementation,
organizations can avoid bottlenecks with last-minute assessments
and interrupting the rapid delivery of technology,
which may even improve.
In addition,
they can promote transparency,
build trust,
maintain an excellent reputation
and even increase their revenues
with the help of a staff faithfully committed to security.

DevSecOps adoption challenges

Nevertheless,
challenges can also arise for organizations
to adopt the DevSecOps culture.
One of the most commonly mentioned roadblocks is internal resistance to change.
Realigning or redefining people’s ingrained modi operandi and mindsets
is often not a piece of cake.
Development and operations teams may see the security team
as a hindrance to the rapid delivery of results.
They may have become accustomed to seeing it
as a team with different priorities,
previously working in a silo
and even as an add-on in later stages of the SDLC,
which should not disrupt their workflow.
After all,
they may believe that security is synonymous with slowdown,
stagnation and even limitation of creativity.

Lack of knowledge about security and requirement compliance
is also considered a challenge for DevSecOps implementation.
It is common to find that developers lack security-related skills.
Ridiculous ideas can even arise from misunderstanding
the DevSecOps practice,
such as that this method leads to a greater number of security issues.
What people is failing to see clearly is that
existing issues are identified and reported in organizations
thanks to this method,
something that doesn’t normally happen
with a simple DevOps methodology.
Many want to ignore that they are at risk.
They simply close their eyes until the impact wakes them up.

Another challenge in the implementation of DevSecOps
is related to tools.
Usually,
DevOps tools such as those for CI/CD,
source code management,
code review, and build, among others,
come from different vendors.
Everything can be further complicated
with the addition of security testing tools.
With the absence of documentation and training,
developers may find it challenging
to choose among the available tools.
Integrating the tools into DevOps pipelines can be complicated
and time-consuming for them.
Moreover,
they may struggle to combine and reconcile results
from diverse resources,
especially if they are from different providers.

Obviously,
monetary challenges can also arise.
Changes in business practices can be costly.
This is an impediment for many companies
when the short and long terms are not evaluated.
For example,
training the team and acquiring tools can involve high costs
in the short term.
Still, a fast release of secure and high-quality products
can generate profits in the long term,
and the prevention of cyberattacks can avoid further elevated costs.

DevSecOps strategy: best implementation techniques

In accordance with the principles or basic steps mentioned above,
we recommend the following practices
for correctly implementing the DevSecOps culture in your organization.

• Gradual cultural change:
  As mentioned above,
  change starts with people.
  The adoption of the DevSecOps culture can happen
  as it occurs with many other trends,
  that is,
  with a gradual chain effect.
  We do not recommend immediately promoting the methodology
  for all your organization’s teams.
  You can start with small groups of individuals
  who have already shown a strong interest
  that fits the purposes of DevSecOps
  to incorporate this culture with new practices in their daily work.
  From there,
  the achieved benefits can serve as an inspiration
  to add more members of your organization
  to a successful turnaround.
  Of course,
  you must remember that
  this is not about giving birth to a new team called “DevSecOps.”
  Team members in your organization will begin to transition
  to a mindset where everyone is responsible for security.

• Security training and practice:
  Those who are already somewhat immersed in security theory and practice
  within your organization
  can serve as support to take the first steps in DevSecOps,
  possibly accompanied by external specialists in the field.
  With the latter,
  you can get security assessment services
  before starting development cycles.
  Together with your team,
  they can help you with threat modeling
  and defining which security controls and requirements to implement.
  But,
  with the help of the former,
  you should immediately start to face the challenge of lack of knowledge.
  So-called Security Champions,
  sometimes in the position of DevSecOps engineers,
  can establish knowledge-sharing plans
  and conduct formal in-house training
  to increase security awareness within each team.
  Through them and even online courses,
  your teams should receive training in best practices
  for secure coding
  and security issues handling and remediation.
  Naturally,
  they should witness and participate
  in the identification of vulnerabilities in your organization’s products
  and in their remediation,
  receiving continuous feedback.
  To further develop their expertise and trust,
  they can also resort to earning certificates.

• Choice of moments for security activities:
  Before thinking about what types of security activities
  to implement in your organization,
  it’s prudent to reflect on the moments of the SDLC
  where they will be applied.
  By defining these points
  and through the discussion and analysis of security,
  it will be easier for you to choose the suitable activities
  and tools to implement.
  For example,
  considering the first phases of the DevOps pipeline,
  the above is more specifically directed to the initial planning process.
  In the coding phase,
  activities such as code review and security protocols for passwords
  and other sensitive information
  are often used.
  Then,
  in the building phase,
  having added code to the repository,
  static application security testing
  (SAST)
  and software composition analysis
  (SCA)
  can come into play.
  The former reviews code for vulnerabilities
  whereas the latter reviews code dependencies.
  In the testing phase,
  having a product ready to run and be tested,
  dynamic application security testing
  (DAST) can be used.
  This method does not access code
  but sends attack vectors to the endpoints of running applications.
  Penetration testing
  can be performed later in the DevSecOps lifecycle,
  in the releasing phase.
  This method relies on hackers
  who try to bypass controls,
  create custom exploits, etc.

• Automation of security activities:
  To automate tools and processes related to security
  within the DevSecOps methodology
  is useful to avoid undermining the purpose of the DevOps approach
  of injecting speed.
  Process automation allows processes to take place
  consistently and iteratively.
  DevSecOps automation tools reduce burdens by delivering early warnings
  or relevant information to developers
  for quick remediation of security issues.
  However,
  it’s important you determine how far automation should go
  because manual interventions are always necessary,
  for example penetration testing.
  Certainly,
  the manual effort remains an indispensable component
  for accuracy and depth.

  Of note is that
  software and standards for its regulation are constantly changing.
  Therefore,
  automation for policy evaluation and compliance is quite helpful.
  Based on the industry your organization belongs to,
  your team selects security requirements they need
  or are required to comply with,
  e.g., PCI DSS,
  HIPAA,
  GDPR.
  Once the requirements are coded,
  automation allows you to quickly verify in the code or product
  if they are being violated
  and notify staff for prompt resolution.
  In addition,
  when you get compliance monitored
  and receive complete software statuses continuously,
  you can expedite response actions
  to avoid costly fines and regulatory lawsuits.

• Incremental security assessment:
  In integrating and implementing security activities,
  it’s wise to go slowly,
  without inordinate aspirations.
  To do otherwise,
  bombarding developers with a myriad of findings
  to tackle in short periods
  can lead them to feel reluctant to work on fixing them.
  So,
  instead of running full tests every time,
  a gradual assessment may be more reasonable,
  for example,
  in early cases,
  only attending to areas,
  or looking for vulnerabilities,
  of high priority.
  Later on,
  the following tests or security activities will serve
  as a complement for a broader and deeper assessment
  before going to production.
  Additionally,
  a significant recommendation for the sake of agility is that
  your organization’s team of developers always submit code
  in small chunks for review.

• Manual security activities:
  As previously stated,
  while automation is relevant in adopting DevSecOps,
  manual activity continues to be especially important.
  Automated vulnerability detection tools still report lies
  (false positives)
  and make omissions
  (false negatives).
  Manual assessments can do checks on this
  and more in-depth scans.
  For instance,
  the manual exercise can focus on tasks from the attackers’ perspective
  to exploit vulnerabilities in a controlled manner
  and evaluate potential impacts on the organization
  (ethical hacking).
  The recommendation is that
  your organization have its systems assessed
  in continuous penetration tests
  that maintain a strong remediation culture.
  Just regular penetration tests are not recommended,
  since the period of time between one test
  and the other
  could give threat actors the chance
  to take advantage of your system’s risk exposure.

• Measuring performance and progress:
  Measurement is part of the proper implementation of DevSecOps.
  The ideal is to collect data from your organization
  on its performance within the new methodology,
  organize it carefully and establish meaningful metrics.
  Among the data to be captured may be,
  for example,
  those related to security tests and their findings,
  as well as remediation and deployment activities.
  Metrics allow keeping a record of progress.
  It is of great benefit to have a platform
  that eliminates noise in collecting data
  from different sources.

• Learning by feedback:
  Measuring successes and failures will always be essential
  in DevSecOps adoption.
  But even more important is that those records serve
  to optimize processes within your organization.
  In continuous software integration and deployment,
  there will always be results to compare and analyze.
  The detection of what made things better or worse in a process or cycle
  is something you can transmit to your teams as feedback
  in the hope that it will lead to learning.
  The sooner it is transmitted, the better.

• New governance:
  Classic governance can mean delays in software delivery
  that in no way fit within the DevSecOps culture and mindset.
  The suggestion then is to turn again to automation.
  You can automate verification activities
  such as controls before the software is released to production.
  There is no need to manually assess a final security status,
  apply pre-selected exceptions
  and break the build when there are unfixed issues.
  To adopt new governance like this,
  within DevSecOps,
  you must have the collaboration and approval of your teams.

If you want to learn about DevSecOps best practices,
i.e.,
the actions that keep your implementation alive,
go to this post.

DevSecOps tools and resources

DevSecOps implementation includes tools
for different security testing types
integrated into the SDLC.

• SAST:
  Tools for this type of testing scan code
  that is not running
  to detect coding and design errors
  that may create exploitable weaknesses.

• SCA:
  Tools for this type of testing
  scan code and files of open-source and third-party components
  to identify known vulnerabilities and licensing issues.

• DAST:
  Tools for this type of testing,
  which do not require access to source code,
  assess running applications to detect vulnerabilities
  related to their deployment configuration, data,
  and business logic.

Some recommended considerations for the selection
of DevSecOps products include the following:

• It is easy to install,
  configure and use.

• It is highly accurate,
  i.e., generates low false positive and false negative rates,
  and looks for what you need it to look for.

• It is fast enough to work within your SDLC.

• It covers policies that your company needs to cover.

• It can work continuously,
  in parallel and integrated with other tools in use.

Additionally,
we would like to highlight a couple of resources
related to the previous tools
that are pretty useful in the implementation of DevSecOps:

• Penetration testing:
  In this security testing methodology,
  in which the manual work of ethical hackers predominates
  over checks by automated tools,
  real attacks are simulated to identify vulnerabilities
  that threat actors in a given environment could exploit.

• Attack resistance management platform:
  This is another type of tool
  that facilitates the management
  and remediation of security vulnerabilities.
  It consolidates data obtained by different methods and tools,
  makes it easier to understand and analyze the detected problems,
  and prioritizes the key findings for prompt remediation.

Learn here
how Fluid Attacks uses DevSecOps tools.

Implement DevSecOps with Fluid Attacks

At Fluid Attacks,
we’re ready to help you in the transformation of your organization,
implementing DevSecOps.
We have certified and experienced security professionals
in charge of integrating security processes and tools
from the beginning and throughout your SDLC.
In a single solution,
we include automated tools for security testing such as SAST,
DAST and SCA.
Our ethical hacker team adds penetration testing
or breach and attack simulation
procedures
and guarantees you low false positive and false negative rates.
Further,
our security tests can check around 50
international reference standards
for your compliance requirements.
All security vulnerabilities
we detect in your software are reported in a single place,
our Attack Resistance Management platform (ARM).
The ARM lets you know the security status of your systems and apps,
learn in detail about the vulnerabilities detected
and prioritize them for prompt and correct remediation.
Additionally,
the ARM allows you to track treatments
and see metrics you can use to benchmark
and make better decisions,
among many other things.
At Fluid Attacks,
we hack your software constantly
to stay one step ahead of malicious attackers.
Furthermore,
our DevSecOps solution makes security permeate your teams
so that it is understood as everyone’s responsibility.

Do you want to know more about DevSecOps?

For more information about Fluid Attacks' DevSecOps solution
and how it can benefit your organization,
follow this link
or contact one of our experts.
We also invite you
to learn how our services are key
to implement DevSecOps in AWS (here)
and Azure (here).
Additionally,
here are two of our posts
that answer the following DevSecOps questions:
What is DevSecOps
and what does a DevSecOps engineer do?

*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Felipe Ruiz. Read the original post at: https://fluidattacks.com/blog/how-to-implement-devsecops/