Many successful cyber attacks result from the exploitation of application vulnerabilities, and strong network security may not be enough. No matter how strong the network security is, hackers can find ways to break into it. Sometimes they are inside an organization’s network and do not exploit a vulnerability for many years. Vulnerable buffer overflow attacks and code injections can be ongoing for a very long time and result in major data breaches, ransomware, or loss of service.
This leaves organizations with a more difficult task: to protect their systems at the software level. This way, companies can minimize the damage that hackers can cause once they gain access to a given system. This process begins with securing the software at the development level. It is already an increasingly important topic on the agenda of CIOs and CISOs.
Stronger security begins during software development
At the same time, the vast majority of companies use open source software for their development projects because it gives them many more options and libraries allowing rapid innovation. Open source is not inherently less secure than proprietary software, but there are a few specific considerations. The good news is that while security risks are a reality, they can be mitigated with achievable steps during software development.
While security software tools have an essential role, organizational culture, management and processes are essential to reduce vulnerabilities. Software development – which today almost always includes open source – can quickly become an unmanageable sprawl. This is especially true for larger systems, where there are hundreds, sometimes thousands, of libraries (dependencies) and software introduced by different people, often from different locations and without adequate communication between these parts. This is why software development should include compliance processes according to company policies, consistent service level agreements (SLAs), ongoing supervision and technical support (which can be best provided by a third party, as internal expertise is often limited), and a source selection process that assesses the health and proactive support of the community before integrating open source packages.
One of the best things about open source is knowledge sharing, and that extends to security. While one of the arguments against open source is that the code is visible to everyone, so are the vulnerability fixes. There will likely be regular updates to fix new vulnerabilities in open source software with strong community support. However, companies should regularly check them proactively: the community will not contact them.
One valuable resource is the National Vulnerability Database (NVD), which is always relevant to developers around the world when they are based in the United States. This standards-based vulnerability management data repository includes reference databases of security checklists, security-related software vulnerabilities, misconfigurations, and impact metrics. Associated with each vulnerability is a Common Vulnerability Exposure (CVE), which aims to identify, define and catalog publicly disclosed software vulnerabilities based on a Common Vulnerability Scoring System (CVSS). This helps security professionals and developers prioritize the most severe vulnerabilities with critical and higher risk.
All of these resources are beneficial to developers, but they are based on known reported vulnerabilities. While this happens often, it is not universal (by the way, this applies to proprietary software, where there is even less information sharing). Developers rely on sharing information about vulnerabilities they discover and subsequently fix.
Additionally, if a business is operated successfully and a major data breach occurs, it is not currently required to report details of how it was accomplished. Compare that to the aerospace industry, where there would be a detailed examination and analysis of a plane crash. So software security needs its own disclosure and responsibility in the “black box”. Security attacks can have serious consequences outside of the digital world, such as recent breaches resulting in the unavailability of electricity or fuel.
All of this points to a change in attitude towards safety, and luckily, it is starting to happen. For example, the Open Source Security Foundation does a great job – and recently received an annual commitment of $ 10 million from companies such as Amazon, Google, Facebook, Microsoft and others. The more software developers and vendors can engage with and provide support, the better the opportunities to protect software in the future, with actions such as vulnerability disclosure and the creation of Software BOMs (BOMs). .
Internally, there is also a need to focus more on training developers to be more security conscious. Traditionally, security was not part of the developer’s role: theirs is to create functional code. This must – and is starting to – change, especially with the advent of movements like “Shift Left” and “DevSecOps”, in which security testing and analysis becomes more important early in the development cycle. However, to reduce the impact on developer workload, these processes should be automated as much as possible. Automation also helps reduce the risk of manual error and keep pace with the speed of many projects. Testing and monitoring should improve, not slow down, development.
Several types of relevant tools are available, both commercial and open source, including Static Application Security Testing (SAST), which involves inspecting and analyzing code even as it is written to find and stop problems. faults entering production. SAST tools are like having a security expert looking over a developer’s shoulder, keeping an eye out for potential vulnerabilities and vulnerabilities. SAST tools can also help with standards compliance.
Dynamic Application Security Testing (DAST) is perhaps more familiar to many people, in which the tests are performed by “attacking” a running web application from the outside. Testing through the web front-end helps identify potential security vulnerabilities or architectural weaknesses.
For open source security, Software Composition Analysis (SCA) is a very useful security tool, with several good commercial and open source options. With SCA, open source libraries (dependencies) used in the source code of applications are analyzed. By identifying direct dependencies and transitive dependencies, the tool cross-checks against a vulnerability database such as NVD to determine the existence of vulnerabilities (CVE) and the corresponding CVSS score.
There are, of course, well-established security processes, such as penetration testing, whereby a hacker tries to penetrate an organization’s networks and applications to discover potential exploits and vulnerabilities. These have a lot of advantages, but they are not enough on their own. It’s like having locks on a door: the more, the better – but eventually a talented thief will find a way in. What matters is making sure that when he does, valuable assets are not within his reach.
Whether open source or proprietary, application security is a complex challenge. For companies that want to improve that security, streamlining processes, instilling cultural attitudes, adding security training, and using the right tools is a good place to start.
Javier Perez, Chief Evangelist for Open Source and API Management, Perforce software