How Organizations Can Protect Modern Software Against Hackers
As cloud-native technologies disrupt the Application Security (AppSec) market, forward-thinking enterprises are shifting their security to the left. What are some of the top weaknesses that modern applications suffer from, and what lies at the root of many of these vulnerabilities? Crucially, what can organizations do to address them and protect themselves from hackers?
Based on the latest insights from the Open Web Application Security Project (OWASP), broken access control, cryptographic failures, and code injection attacks are some of the top web and app weaknesses, says Lawrence Crowther, head of solutions engineering for APJ at Synk.
While the term “SQL injection” would probably ring a bell for most, it is part of a broader set of code injection methods that see attackers exploit software flaws as a way to inject their nefarious code. This can come in the form of either SQL statements to reveal or rewrite vital data in the database, or Unix commands that are executed on the host server – and Crowther warns organizations to keep an eye out for these.
“Though [code injection], which includes cross-site scripting attacks, has slipped from the top spot to number three on the list, I would still consider this to be one of the most popular ways for hackers to infiltrate systems,” he noted.
The threat from within
But why are software vulnerabilities still an issue in modern software, considering the growing awareness of writing robust software and years of patching cycles? Crowther explained: “One of the biggest changes in software development in the last 10 years is the exponential growth in using open-source libraries to construct applications. Organizations all over the world, from every vertical imaginable, use open-source code to power their business.”
Indeed, as much as 90% of all commercial software developers use open source components within their applications, he said, pointing to prior studies from analyst firms such as Forrester and Gartner. Crowther emphasized that it is not open source that is the issue, but the vulnerabilities that may be embedded within the code.
“Open source is great, but do developers know the source of the libraries they use from the internet? The problem is amplified because it’s not just the libraries themselves you have to worry about, it's all the other dependencies that those libraries include as well. We call these transient dependencies, and this is where most of the vulnerabilities in the open-source ecosystem lie,” said Crowther.
“The best developers in the world are not immune to adding vulnerabilities into their applications. As more code is committed to projects around the world, statistically, this means that the number of vulnerabilities will probably increase.”
The onus is hence on organizations to staunch the influx of vulnerabilities by implementing proper DevSecOps programs to find and fix vulnerabilities before they make their way to production systems, says Crowther. Crucially, the tools should also be integrated into developers’ tooling so that they are empowered to fix issues quickly, without compromising their productivity.
Getting started with shift left
So how can organizations start shifting left? Also, does shifting left mean that the security team is now obsolete? On the contrary, says Crowther, who argues that the security team has a huge role to play in the overall shift left and DevSecOps movement.
“Developers may not be versed in the domain of application security, so the security team has to play the role of providing enablement and guidelines, as well as the guardrails in the form of tools and platforms to help development go fast while staying secure,” he said.
Importantly, shifting left entails not just doing security earlier, but having a different mindset about their secure posture. “Chances are you have pen testing and security audit scripts which you typically execute towards the end of the development process. Shifting left does not mean you simply take those same end-to-end tests and run them earlier in the process. This would cause friction with developers and reduce productivity,” said Crowther.
“Instead, you need to select tools that are natively integrated into their IDE so that developers can get feedback in real-time about their code and dependencies as they write their applications. It's much cheaper to do it then than when in production.”
There is also more to the shifting left than providing security coverage across the software development life cycle (SDLC), says Crowther. From the source code (commit), CI/CD (build), and even at the deployment and production stage (deploy), organizations must check for vulnerabilities or configuration drift at every stage as part of a continuous security process.
People, process, and technology
Developers today have more responsibility than they had before, especially when one considers the nature of cloud-native applications and how everything is becoming code, says Crowther. “A typical [cloud native] application is made up of its unique code and the various open source libraries it defines as its dependencies.”
“[The application] will most likely be deployed to a docker container image so would have a Dockerfile configuration, it may also be deployed to Kubernetes so will have YAML config files and may also use Terraform to define the cloud infrastructure. All these are codified and stored in a Git repository and updated as the project evolves. This is a big responsibility for developers because now they have to also worry about securing these assets too,” said Crowther.
Fortunately, a range of cutting-edge security platforms is now available, empowering developers to build secure applications within the development process.
“DevSecOps programs have been set up using tools like Snyk.io to assist developers to make this transition easier to cloud-native. Many organizations are now setting up ‘AppSec’ teams which are multi-skilled professionals who understand engineering practices and security. They can have empathy for both sides of the organization and institute a great culture of collaboration.”
The right tools and security-aware teams are only half the story, however: “The other piece is about how the team collaborates across the different functions to quickly respond to changing demands of the business – and still keeping a good security posture. This directive must come from the leadership: to foster engagement between the development organizations, operations, and security.
“Ultimately, all parties need to take collective ownership of the project from day one instead of security being an afterthought,” Crowther summed up.
Paul Mah is the editor of DSAITrends. A former system administrator, programmer, and IT lecturer, he enjoys writing both code and prose. You can reach him at [email protected].
Image credit: iStockphoto/Dilok Klaisataporn
