Back
Addressing Application Security Challenges in the SDLC
In recent years, more organizations have adopted the “shift left” mentality. This concept moves application security testing earlier in the software development life cycle (SDLC) versus the traditional method of implementing security testing after deployment of the application.
By shifting left, an organization can detect application vulnerabilities early and remediate them, saving time and money, and ultimately not delaying the release of the application.
But not everything comes wrapped in a beautiful bow. In application security, I witnessed that shifting left comes with its fair share of trouble – two in fact:
- Overworked and understaffed teams
- Friction between application security engineers and development teams
During his time at Microsoft, Idan Plotnik, co-founder and CEO at Apiiro experienced these two roadblocks and created an application security testing tool that addressed both. I recently had the opportunity to sit down with him to discuss the concept of shift left and other application security challenges.
Continue reading for highlights from our conversation including contextual pentesting, open-source security, and tips on how a business can better prepare for remote code execution vulnerabilities like Log4Shell. For more, listen to the full episode on the Agent of Influence podcast.
Why is it important to get more context on how software has changed and apply that to pentesting?
Idan Plotnik: One of the biggest challenges we are hearing is that organizations want to run penetests more than once throughout the development life cycle but are unsure of what and when to test. You don’t want to spend valuable time on the pentester, the development team, and the application security engineer to run priority or scoping calls in every release. You want to identify the crown jewels that introduce risk to the application. You want to identify these features as early as possible and then alert your pentesting partner so they can start pentesting early on and with the right focus.
It’s a win-win situation.
On one hand, you reduce the cost of engineers because you’re not bombarding them with questions about what you’ve changed in the current release, when and where it is in the code, and what are the URLs for these APIs, etc.
On the other hand, you’re reducing the costs of the pentest team because you’re allowing them to focus on the most critical assets in every release.
Nabil Hannan: The traditional way of pentesting includes a full deep dive test on an application. Typically, the cadence we’ve been seeing is annual testing or annual requirements that are driven by some sort of compliance pressure or regulatory need.
I think everybody understands why it would be valuable to test an application multiple times, and not just once a year, especially if it’s going through changes multiple times in a year.
Now, the challenge is doing these tests can often be expensive because of the human element. I think that’s why I want to highlight that contextual testing allows the pentester to hone and focus only on the areas where change has occurred.
Idan: When you move to agile, you have changes daily. You need to differentiate between changes that are not risky to the organization or to the business, versus the ones that introduce a potential risk to the business.
It can be an API that exposes PII (Personally Identifiable Information). It can be authorization logic change. It can be a module that is responsible for transferring money in a trading system.
These are the changes that you need to automatically identify. This is part of the technology that we developed at Apiiro to help the pentester become much more contextual and focused on the risky areas of the code. With the same budget that you have today, you can much more efficiently reduce the risks.
Learn more about the partnership between NetSPI and Apiiro.
Why is open-source software risk so important, and how do people need to think about it?
Idan: You can’t look at open source as one dimension in application security. You must take into consideration the application code, the infrastructure code, the open-source code, and the cloud infrastructure that the application will eventually run on.
We recently built the Dependency Combobulator. Dependency confusion is one of the most dangerous attack vectors today. Dependency confusion is where you’re using an internal dependency without a proper naming convention and then an attacker goes into a public package manager and uses the same name.
When you can’t reach your internal artifact repository or package manager, it will automatically fall back and access the package manager on the internet. Then, your computer will fetch or download the malicious dependency with the malicious code, which is a huge problem for organizations.
The person who founded the dependency confusion attack suddenly receive HTTP requests from within Microsoft, Apple, Google, and other enterprises because he found some internal packages while browsing a few websites. He just wanted to play with the concept of editing the same packages with the same name to the public repository.
This is why we need to help the community and provide them with an open-source framework that they can extend, so that they can run it from their CLI or CI/CD pipeline for every internal dependency. Contributing to the open-source community is an important initiative.
What can organizations do to be better prepared for similar vulnerabilities to Log4Shell?
In December 2021, Log4Shell sent security teams into a frenzy ahead of the holiday season. Idan and I discussed four simple steps organizations can take on to mitigate the next remote code execution (RCE) vulnerability, including:
- Inventory. Inventory and identify where the vulnerable components are.
- Protection. Protect yourself or your software from being attacked and exploited by attackers from the outside.
- Prevention. Prevent developers from doing something or getting access to the affected software to make additional changes until you know how to deal with the critical issue.
- Remediation. If you do not have that initial inventory that is automated and happening systemically across your organization and all the different software that is being developed, you cannot get to this step.
For the full conversation and additional insights on application security, listen to episode 39 of the Agent of Influence podcast.
