Bridging the gap between security and developers

Regardless of what you need, there is an app for that. In fact, there are 1.81 million apps on Apple’s App Store in 2024, according to Business of Apps. This growing trend has spread from our pockets to our businesses with more adoption of Software as a Service (SaaS) and cloud computing. The average company has 371 SaaS applications, while IDC found companies spent $315.5 billion on public cloud services during the first half of 2023.

All of this software and all of these applications are made by humans, and people, notoriously, make mistakes. Mistakes in software development increase the likelihood of attacks, which leads to security incidents. Multiply these risks by the size of your tech stack, and keeping your environment secure seems nearly impossible.

Identify problems early

To ease some of the risk and security burden, find the issues earlier in the software development process. This is called a “shift-left” concept as it involves running security scans and reviews earlier in the software development life cycle (SDLC). Scanning software in the continuous integration/continuous deployment (CI/CD) pipeline flags problems that need attention before they become vulnerable to attackers. By finding bugs, misconfigurations, or vulnerabilities earlier, you can also fix them sooner and at a lower cost than when those same issues are running in production applications or are part of software that is deployed to thousands or millions of real-world assets.

Though the concept of shift-left security has been discussed as a best practice for the past few years, it does not appear to be well implemented. Data from the Sysdig 2024 Cloud-Native Security and Usage Report found that scans on production systems failed more often than those in the CI/CD build pipeline. The report identified 91% of production scan policy failures, while CI/CD scans failed at 71%. CI/CD scans take place before production runtime scans, so any failures captured in the CI/CD build pipeline should be corrected before they are scanned in runtime. So why are we seeing such a high failure rate during runtime if the shift-left concept is the best practice?

Making changes to your processes

First and foremost, improving collaboration between teams rather than just addressing security requirements alone will almost always prove to be more effective and sustainable. In the eyes of a developer, shift-left requires added responsibilities for fixes and changes without additional assistance. For them, shifting left may look more like a workload increase than a change in approach that can reduce security risks.

To overcome this hurdle and make shift-left processes work, security personnel must understand how their developer colleagues actually work in practice. Do the applications they build follow traditional design principles, are they cloud-native applications built to be distributed, immutable, and ephemeral (DIE), or is there a combination of builds in transition from traditional to cloud-native?

By better understanding how complex their environments and application builds are at the core, security teams can help developers navigate what risks exist in their applications and how to prioritize and mitigate the biggest threats before they’re realized in production. This should include determining how significant the risk is to your organization and environment, and what steps are required to mitigate the risk. This process ensures that developers can focus on any changes they have to make where they are needed the most, such as exploitable critical vulnerabilities or misconfigurations.

Similarly, security teams and their tools can also flag where wasted components or permissions might be included in standard container images. Developers often use software containers or machine images as standardized templates for deployment. If those templates contain out-of-date components, however, every use of that template will be flagged as an additional security risk. Updating developer workload templates will reduce the number of security alerts and risks and minimize repetitive work efforts.

Improve security before production

Ideally, software containers are meant to be immutable. This means that a workload does not change during runtime. Container drift, or modification and updates made to a container while in production, often triggers security alerts but is common practice for developers. If developers restrain themselves from workload modifications during runtime (drift control), security teams can have more sensitive and higher fidelity detections set for container drift, indicating potentially malicious activity instead of development noise.

Runtime scans are more accurate in highlighting security issues that are active in a production environment. These scans keep the security issues closer to the security team rather than passing off security problems to developers. Problems that exist in production environments have the potential to negatively impact business operations.

Long-term security gains

We all rely on software and applications in our daily lives and our organizations. This software must be kept secure. We can improve its security by shifting left and keeping to the “secure-by-design” mantra. Software and applications that are built securely have less attack risk and will cause fewer policy scan failures, reducing the security burden on both security and developer teams.

In practice, security teams need to work with developers to indicate where those potential risks exist and how they can be removed. At the same time, developers can educate security teams and collaborate with them to stop issues from getting into code or infrastructure components. This teamwork, and sharing common goals, will improve overall software quality and security across entire organizations.

We've listed the best mobile app development software.

This article was produced as part of TechRadarPro's Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro