Secure Software Engineering Habits

As mentioned in my previous post 'Building Software Immunity,' an application security mindset needs to be at the core of software engineering practices. Just as good eating habits bring nutrients into our bodies, good engineering practices bring internal quality and immunity into our software to help fight off any unforeseen attacks in the future. This post is an attempt to explore some of these ideas and practices that can help developers or tech leads make software and, eventually, the end-users secure.

Shift-Left Approach

With the rise of Twelve-Factor cloud-native applications, infrastructure has become part of software applications. Development teams (leads, software developers, product owners) are building software rapidly with various CI/CD (DevOps) and IaC (Infrastructure As Code) tools. In such agile and evolving environments, the security of the software can be easily overlooked. As pointed out by Richard Seiersen in A Modern Shift-Left Security Approach, incorporating security in early phases of software development has typically been costly and time-intensive. An improved approach is to embrace security features right from the beginning when requirements are formed. That is, security requirements can be augmented with user stories to emphasize these aspects in rapid development environments (for more directions, refer to C1: Define Security Requirements | OWASP).

Furthermore, using attack surface analysis in the early phases of the development cycle can help identify and provide defense-in-depth protection from the very beginning. Attack Surface Analysis — OWASP Cheat Sheet Series is an excellent guide.

A Forrester report indicates security is a major concern while adopting containers for application development. Although the configuration of containers plays a major role in ensuring security, it underscores the need of applying security concepts right at the core of the application by following good programming habits.

Secure Coding Practices

Security is a complex domain and secure coding practices are usually not part of academic instruction. Although comprehensive standards for security are difficult to grasp, resources such as the OWASP Cheat Sheet Series and SEI CERT Coding Standards are evolving and helping us to understand how secure coding can be incorporated into our development habits.

• Choosing a programming language or framework or being aware of existing frameworks is the genesis of secure coding practices in any software development project. Various features of any programming language or framework in use need analysis so that teams are well aware of any vulnerable features that might lead to attacks, like when dependency hijacking software was used to attack the supply chains of more than 35 organizations. Conducting the appropriate research before using any framework or having a security awareness of existing frameworks can bring relevant mitigation approaches into practice.
• Following basic coding standards can make software applications inherently secure. Improper input validation and insecure direct object reference prevention (IDOR) may not bring direct threats, but they have the potential to reveal internal information or patterns used within applications and attract severe attacks to the system. Such issues can be easily prevented with good programming standards and code reviews conducted with a security mindset.
• Exception handling deserves its own share of the focus. For instance, it is a common practice to log error scenarios (exceptions) in programs. A common practice by many developers is to print exceptions for debugging purposes and continue the flow. The example below illustrates this:

x

public class ApplicationProperties {

    public void loadProperties(String fileName) {

        Properties properties = new Properties();

        try {

            properties.load(ApplicationProperties.class

                    .getClassLoader()

                    .getResourceAsStream(fileName));

        } catch (IOException e) {

            e.printStackTrace();

        }

    }

}

Printing exceptions might seem like something to troubleshoot if the application fails during runtime. Nevertheless, it can leak critical information about the internal structure or the state of processes and (equally important) continue the application in this erroneous situation.

AMQ-1272 in ActiveMQ was a live example of such major security threats. An excellent guide to better understanding and tackling these cases can be found here: Do not suppress or ignore checked exceptions: SEI CERT Oracle Coding Standard for Java.

• Software Composition Analysis is another necessary imperative in modern software applications which are built by wiring various third-party or open-source components (Using Components with Known Vulnerabilities has been on the OWASP Top 10 for a while now). Proper Component Analysis can be carried out before or while using any third-party or open-source libraries. Vulnerable components, frameworks need to be upgraded or replaced with more secure ones.

These aspects of programming might overwhelm developers who are handling changing requirements, as well as build and infrastructure technologies. The addition of security experts can bring value to the project in the long run. Various tools available in the market are very helpful in taking some cognitive load off of development teams.

That takes us to the next topic...

Using Tools and Frameworks

Tools and frameworks from trusted sources can be real-time and effort savers for tech leads and developers in identifying security flaws much earlier in development. These can be plugged into IDEs or build pipelines to prevent vulnerable code from being released.

• Plugins like Snyk Vulnerability Scanner on IntelliJ can help developers to identify and fix vulnerabilities before code is committed.
• OWASP Dependency-Check and Retire.js can be used to identify vulnerable libraries or dependencies before they are used or committed to a source code repository. Incorporating them in CI pipelines also allows developers to secure the software supply chain.
• Penetration testing tools like OWASP ZAP are very useful during the development of web applications to identify and fix run-time vulnerabilities.

Although these are just examples, due diligence is required to use the right tools for each project.

In a Nutshell

Secure engineering practices are the first step towards software security. Shifting security left in the software development process brings proactive security controls to the beginning of any project and helps to embed security into the core of the software. It saves us from any rework which might be extremely costly in terms of time, effort, and, eventually, money in later phases.

Various tools and techniques are available to rescue development teams overwhelmed with security concepts and the complexity that comes with it. A more prudent and feasible approach is to embrace it before it's too late!