{"id":1263,"date":"2021-07-02T13:06:00","date_gmt":"2021-07-02T13:06:00","guid":{"rendered":"https:\/\/expleo.com\/global\/en\/?post_type=insight&p=1263"},"modified":"2025-08-28T09:30:39","modified_gmt":"2025-08-28T09:30:39","slug":"asg-series-the-urgent-need-to-shift-left-security-testing","status":"publish","type":"insights","link":"https:\/\/expleo.com\/global\/en\/insights\/blog\/asg-series-the-urgent-need-to-shift-left-security-testing\/","title":{"rendered":"ASG Series: The urgent need to shift-left security testing"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Security testing is a complicated and expensive \u2013 but very necessary \u2013 stage of the software delivery cycle. With the growth of cloud-hosted applications and unprecedented home working due to the pandemic, has automated security testing in a DevOps pipeline matured enough to mitigate the real risks of cyberattack? The\u00a0recent \u201cransomware\u201d breach on the Colonial oil pipeline in the US<\/a>\u00a0suggests not.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"A\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Historically, security testing has been a complex, largely manual and deeply technical discipline within software testing. It\u2019s typically an activity that is scheduled towards the end of a delivery cycle and often, when an application is deemed close to production readiness.<\/p>

More and more organisations are adopting a DevOps approach to their development practice and moving to microservice architectures. We are therefore seeing more aggressive delivery times and smaller modules of work being delivered.<\/p>

However, this increase in the velocity and variety of service releases brings an ever-increasing attack surface for malicious actors. It also creates impossibly-small time windows for executing comprehensive manual security checks. How do we mitigate these risks while still maintaining aggressive release velocity?<\/p>

\u00a0<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Defence in depth<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The big players in the cloud space (Amazon AWS, Microsoft Azure, Google Cloud) are doing their bit to help. On the deployment side of the equation, they are providing multiple layers of protection \u2013 or \u201cdefence in depth\u201d. This is useful for building out a cloud-based infrastructure that\u2019s centred around the lowest level of permission paradigm, where access to resources must be explicitly granted. Other example protections include\u00a0AUTH-N\/AUTH-Z<\/a>\u00a0and the encryption of data at rest using server-side encryption (SSE) routines such as\u00a0AES-256.<\/a><\/p>

This lowest level of permission paradigm means that complex applications that have large architectures (and also ones that don\u2019t) need to implement methods of communicating across cloud resources using Keys and access control lists (ACLs) etc. The larger the architecture, the larger the surface area for attack becomes.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Men\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Unfortunately, the biggest risk of compromise to any application or company is the people who run it. Keys can accidentally be committed into source code repositories. Secure coding principles may not be clearly defined or adhered to. Time pressure on releases can cause many issues to go undetected in a manual security scan. Human fallibility is the recurring factor.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Easy access\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Consider a web-based book-selling application with a subscription service that requires users to provide credit card details to join. The database is securely deployed into a private subnet, with an Access Control List allowing access to only certain source network addresses, as well as an AUTHN\/AUTHZ control for access and privilege protection. It would be natural to assume that these layers of cloud protection mean that the database is nice and safe and cannot be breached externally, right?<\/p>

Alas, that is not the case. The users of the service must enter their card details to the website. Therefore, we can deduce, with a high degree of confidence, that the web page is in the ACL to the database. Already we have a publicly facing access route into the \u201csafe and secure\u201d database \u2013 provided a method of access can be found. The scary truth is that there are multiple methods to attack this database, including SQL Injection, Cross Site Scripting (XSS) etc. To an adept cybercriminal, it\u2019s an open door.<\/p>

Bear in mind this is only one small part of what could be a much larger website with many, many vectors for attacking. How then, can we expect a manual security scan in a short time frame to adequately analyse and test all the possible attack vectors and expose them?<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Vulnerability scanners<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The good news is that the security community is really beginning to step up in the tooling space. There are currently multiple tools on the market, both commercial off-the-shelf and open source, that come under the heading of vulnerability scanners. These tools promise to bring automation to the practice of scanning applications, networks, compute resources etc. for potential vulnerabilities.<\/p>

Recently, I was engaged on a project for a web-based application where my client was interested in reducing the number of issues that were caught in their regular manual pen-testing cycle. Catching these issues earlier not only allows for them to be addressed faster, but it also reduces the costs associated. The further \u201cright\u201d in the cycle a defect is detected, the more expensive it becomes to address.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Hand\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In short, how was this achieved? After a few days spent researching the tools landscape, I shortlisted several tools to be implemented into the development\u00a0CircleCI<\/a>\u00a0pipeline that covered Dynamic Application Security Scanning (DAST), Static Application Security Scanning (SAST) and interactive passive scanning of the web application:<\/p>