Agile Security: How To Secure Your Company’s Continous Delivery Pipeline  

Agile Security: How To Secure Your Company’s Continous Delivery Pipeline  

There are a few things software development companies can do to deliver both high-quality and secure software. Here we show the main practices we can follow to improve and embed security into Agile.

Let’s face it, there is no single, critical activity that can guarantee security in software development. There is no magic recipe or one-fits-all solution for this. However, there are certain practices we can follow to improve and embed security into Agile. Stay with us to know how security and Agile can blend to create secure software. 

THE COST OF INSECURE SOFTWARE 

Software is a human activity and the outcome of a process with many factors affecting software quality. Among these factors, we have the process itself, the specific knowledge, the expertise that team members bring to the table, how well they interact with each other, third-party software, libraries in use, and the tools used to build the software. 

Knowing everything we know today about the impact of poor security, it is surprising that many companies still do not associate security as an attribute to software quality. Insecure software is poor quality software which has a direct impact on customer satisfaction and therefore on revenue. 

According to the Consortium for Information & Software Quality (CISQ), an IT industry leadership group that develops standards for automating software quality measurement, the total Cost of Poor Software Quality (CPSQ) in the US in 2020 was $2.08 trillion, which far exceeds the total wage bill for all software developers/IT workers in the US that the report estimates at $1.4 trillion.  

Insecure software is one of the reasons why companies may have to pay huge fines as shown by the $120 million paid by Morgan Stanley in January 2022, the $21 million by Tesco Bank, and the $7.5 million paid by Google. We all assume a banking system should be one of the most secure and well designed, right? Well, it seems not, as insecure software is everywhere apparently, and not even Google is safe from a software flaw. 

THINGS WE CAN DO TO IMPROVE SOFTWARE SECURITY 

Before we continue, let’s agree on the meaning of software security and secure software. For the purpose of this article, we can use Perforce’s, definition: “Secure software is software that has been developed in such a way that it will continue to function normally even when subjected to malicious attacks.” Synopsis goes more or less the same way when defining what secure software means: “Software security is the idea of engineering software so that it continues to function correctly under malicious attack.” We will add our 2 cents by saying that secure software is also software that fails gracefully when subject to unexpected conditions. 

Let’s now talk about what Secure SDLC (SSDLC) means. As per WhiteSource, in a SSDLC, “Security is integrated throughout the development and delivery cycle and implemented in every stage.” An SSDLC allows for detecting and remedying security issues as early as possible in the software development lifecycle before they reach testing and production environments where these issues demand more time to address and cost more to fix. 

As per SecureCoding, the U.S. Department of Homeland Security (DHS) published a software assurance report that estimates up to 90 percent of security incidents stem from exploits against defective code and vulnerable software. 

There are a few things software development companies can do to move from SDLC to SSDLC and therefore deliver high-quality, secure software. 

Training of – and awareness from – individuals involved in the SDLC 

Software companies have traditionally hired technically strong developers. We need to be careful as being technically strong might not mean they are also capable of writing secure code. Therefore, it is necessary to have specific security training in place to teach them best practices and create a culture around secure code and how to build it. 

Secure Coding Standards 

These are rules and guidelines used to prevent security vulnerabilities that help in preventing, detecting, and eliminating errors that may compromise software security. The company can have a combination of industry standards like the Common Weakness Enumeration, the CERT Coding Standards, and PA-DSS (global security standard that applies to the development of payment application software), as well as additional rules and guidelines designed in-house that make sense to the company and complement the external standards to fit the company’s business. 

Shift Left 

It is of the utmost importance for software companies today to unfold a methodology to decide which tools and best practices will be leveraged at which points within the Software Development Lifecycle (SDLC) to maximize results. It is no longer enough to test for security issues once the software is released from Development to later stages as these issues cost more time and money to address and fix as mentioned before. Security, DevOps, and Development teams need to work together with the common goal of creating secure software. We shift security to the left when we use one or more of the following: 

  • Work on the security requirements and analysis starting from the planning phase. 
  • Follow the secure architecture and coding standard adopted by the company during the architecture, design, and development phases. 
  • Do threat modeling and assessment on your application source code. This is a formal, structured, and repeatable technique for determining and weighing the risks where the software will be vulnerable. 
  • Do vulnerability scanning through Static and Dynamic Application Security Testing (SAST and DAST, respectively) all along the SSDLC. 
  • Keep an eye on the security of third-party and open-source software. Every external software component being integrated into the final solution must meet rigorous security standards as defined by the company. 

Some final words 

Developing secure software demands not only a change in the way software is built but also for the software architects, developers, testers, security practitioners, and everyone else involved in the SSDLC to be aware and knowledgeable about the specific technical aspects related to the construction of secure software. 

Stay tuned for more information on the things a software development company should do to build secure software. 

At Hexacta, we value your business. Come talk to us if you want to know how we can help to secure your business through robust, secure software. 

White Paper

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.