News

Published on July 15th, 2019 📆 | 4710 Views ⚑

0

Prioritize Security Without Slowing Down


iSpeech.org

Getty

In 2017, cyber attacks caused 
$5 billion worth of damages
. As a result, organizations have invested heavily: Gartner
forecasted
worldwide enterprise security spending would reach $96.3 billion in 2018. Despite significant investments, resources remain short and attacks still happen. Skills shortages, technical complexity and need for automation remain major roadblocks.

Meanwhile, business demand for faster deployments has challenged application security. The traditional approach to implementing security at the end of the software development life cycle (SDLC) results in large batches of code review altogether, long after a developer committed the code. This approach halts progress at the very end of the process when changes are costly and time-consuming. Jay Lyman, a principal analyst at 451 Research, concludes, “In many cases, security testing is not being integrated often or early enough in the process for organizations to fully benefit from reduced risk and rework headaches.”

DevSecOps changes that by embedding automated security testing throughout the SDLC, embracing the “everyone is responsible for security” manifesto by integrating it into the developer’s workflow.

A Faster, Safer Security Paradigm

A new paradigm is necessary that can support the fast, iterative value creation processes of DevOps. Security testing must be seamlessly integrated and automated within the DevOps SLDC. Frequent, incremental scans inform developers immediately of security flaws they create.

This is accomplished via automated security checks, built into the continuous integration and delivery (CI/CD) process in order to test committed code. There’s a single source of truth, promoting collaboration between developers and security experts. Developers are empowered to identify and remediate issues within their workflow, and security teams have a dashboard for easy monitoring and remediation.

Gates Are Not The Solution

Traditionally, enterprises have relied upon gates throughout the deployment process to prevent bad code from going to production. However, code can also become vulnerable after it’s been deployed to production due to new exploits and unapplied security patches. Traditional pre-production application security scans will miss these vulnerabilities while security gates can hinder the fix for a non-security issue and slow the process. Additionally, gates amplify the negative consequences of false positives. According to a Sonotype DevSecOps survey, “The noise of false positives can drown out the benefits of security scanning.” Knowing this, developers will not implement the gates and find ways to work around them or remove them.





Instead of gates, reporting is needed to show what in production is vulnerable and the effect of the proposed change to the production environment. This allows security experts to oversee applications and flag abnormalities. Ideally, security checkpoints should not automatically block (or “gate”) a pipeline or automatically prevent a new version from being released to production.

">

In 2017, cyber attacks caused 
$5 billion worth of damages
. As a result, organizations have invested heavily: Gartner
forecasted
worldwide enterprise security spending would reach $96.3 billion in 2018. Despite significant investments, resources remain short and attacks still happen. Skills shortages, technical complexity and need for automation remain major roadblocks.

Meanwhile, business demand for faster deployments has challenged application security. The traditional approach to implementing security at the end of the software development life cycle (SDLC) results in large batches of code review altogether, long after a developer committed the code. This approach halts progress at the very end of the process when changes are costly and time-consuming. Jay Lyman, a principal analyst at 451 Research, concludes, “In many cases, security testing is not being integrated often or early enough in the process for organizations to fully benefit from reduced risk and rework headaches.”

DevSecOps changes that by embedding automated security testing throughout the SDLC, embracing the “everyone is responsible for security” manifesto by integrating it into the developer’s workflow.

A Faster, Safer Security Paradigm

A new paradigm is necessary that can support the fast, iterative value creation processes of DevOps. Security testing must be seamlessly integrated and automated within the DevOps SLDC. Frequent, incremental scans inform developers immediately of security flaws they create.

This is accomplished via automated security checks, built into the continuous integration and delivery (CI/CD) process in order to test committed code. There’s a single source of truth, promoting collaboration between developers and security experts. Developers are empowered to identify and remediate issues within their workflow, and security teams have a dashboard for easy monitoring and remediation.

Gates Are Not The Solution

Traditionally, enterprises have relied upon gates throughout the deployment process to prevent bad code from going to production. However, code can also become vulnerable after it’s been deployed to production due to new exploits and unapplied security patches. Traditional pre-production application security scans will miss these vulnerabilities while security gates can hinder the fix for a non-security issue and slow the process. Additionally, gates amplify the negative consequences of false positives. According to a Sonotype DevSecOps survey, “The noise of false positives can drown out the benefits of security scanning.” Knowing this, developers will not implement the gates and find ways to work around them or remove them.

Instead of gates, reporting is needed to show what in production is vulnerable and the effect of the proposed change to the production environment. This allows security experts to oversee applications and flag abnormalities. Ideally, security checkpoints should not automatically block (or “gate”) a pipeline or automatically prevent a new version from being released to production.

Source link

Tagged with:



Comments are closed.