How it Works

With the full Codebashing offering, AppSec managers are able to cultivate a culture of software security that empowers developers to think and act securely in their day-to-day work. Organizations can engage their remote development teams to participate in:

• Gamified Training – Developers take online, gamified training courses while learning and coding from home.
• Team Challenges – Add a spirit of competition by running challenges that test developers’ AppSec knowledge. Developers will go head-to-head with one another to move up the leaderboard.
• Assessments – With everyone working from home, it’s the perfect time to understand where each developer stands when it comes to their AppSec skills.

To get started, sign up between now and May 31, 2020, and view our FAQ below for more information. Developers can also visit free.codebashing.com to get a quick start on some of the lessons Codebashing offers, free of charge and with no commitment – play now!
Supporting our customers, partners, and the broader AppSec community remains a top priority, and we hope these proactive steps will help organizations continue to deliver secure software throughout these difficult times.
*Terms and conditions apply.

Additional Resources

• Learn more about Checkmarx Codebashing here.
• Follow our social channels (LinkedIn, Twitter, Facebook) for more COVID-19, Codebashing, and AppSec related updates.
• Learn more about how Checkmarx is ensuring business continuity for our customers throughout COVID-19.

FAQ

❯ What is Codebashing?

❯ Who is Codebashing for?

❯ Who is eligible for this offer?

❯ How long is this offer valid for?

❯ How do I get started?

❯ What are the terms and conditions?

What exactly are injection vulnerabilities?

Before going into a short explanation, first let’s discuss how abundant injection vulnerabilities are. For example, Injection has made the OWASP Top 10 for the most critical Web Application Risks in 2010, 2013, and 2017. Injection also made the list on the OWASP Top 10 for API Security in 2019 as well. Clearly, injection risks and associated attacks have been in existence for nearly 20 years and have often been the catalyst in many reported data breaches.

Injection vulnerabilities cause computing systems to potentially process malicious data that attackers introduce. To put it in its simplest terms, attackers inject code into a vulnerable piece of software and change the way the software is intended to be executed. As a result, injection attacks can be somewhat disastrous, since they normally involve data theft, data loss, data corruption, denial of service, etc.

According to OWASP Top 10 2017, “Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.” For more information on SQL injection and LDAP injection for example, Checkmarx provides detailed descriptions in our vulnerability knowledge base.

In light of nearly 20 years of widespread injection vulnerabilities, I asked our guest expert Inon Shkedy to provide his insight on a few questions as shown below. Inon worked closely with Erez Yalon, Head of Security Research at Checkmarx, on the OWASP API Security Project.

Together, they spearheaded the development of the OWASP API Security Top 10 2019, which defines the top ten most critical API security risks.

Guest Expert Interview

…
Question: Why is injection still making the list of Top Ten risks, and shouldn’t this problem have been remedied by now?
Inon:
There are two main trends in the field of injections:
On one hand, some types of injections become less and less prevalent, because of proper security education and a set of modern technologies which address them.
On the other hand, new frameworks and technologies open a door for new types of injections. For example, NoSQL injection is a relatively new attack vector for systems that use NoSQL.
These two trends make injections less severe and prevalent, but at the same time they still have a place on the list.

Question: What is the cause of developers writing injection vulnerabilities into the code they produce?
Inon:
There are a few main reasons:
Lack of awareness: it’s common to see junior software engineers writing code that is vulnerable. The “injection” concept may be not very intuitive for them, and they deliver vulnerable code because it’s the easiest / fastest way for them to implement a specific component.
Rush: we all know how stressful and demanding modern software development environments can be. Concepts like Agile and CI/CD are great for fast delivery, but when developers are focused only on delivering the code, they might forget to check for security issues.
Complexity: APIs and modern apps are complex. A modern app, like Uber for example, might look very simple from the UX (user experience) perspective, but on the backend there are many databases and microservices that communicate between them behind the scenes. In many cases, it’s hard to track which inputs come from the client itself and require more security attention (as filtering and scanning), and which inputs are internal to the system.

Question: What will it take to finally get developers to stop writing injection vulnerabilities into their code, and / or organizations releasing code with injection vulnerabilities?
Inon:
Raising awareness: I believe that secure coding is a result of education. It’s super important to raise awareness by providing security guidelines for new software engineers in the company and to have ongoing training, talks, and discussions about security.
Pre-production automation: use automatic tools like SAST and IAST to find injections vulnerabilities in your code before it gets exposed to the whole world.

Use ORMs: It’s harder to write vulnerable code when you use ORMs. They provide security mechanisms by design.

Conclusion

Clearly, injection flaws must be addressed during the software development process by first detecting them, then mitigating them by fixing the vulnerabilities. If applications with injection flaws make their way to the internet, it’s only a matter of time before they’re found by attackers, and are eventually exploited.

Automation is Essential for DevSecOps

We think that automating the process, particularly using Continuous Integration (CI) and Continuous Delivery (CD) tools, is essential for successful adoption of DevSecOps.

• Continuous integration. Allows a developer to integrate changes into the source code mainline as they finish writing a piece of code.
• Continuous delivery. Allows system components to be updated as needed, rather than waiting to deliver component updates in the next full release.
• Continuous deployment (also known as CD). Allows applications to be continuously deployed, often to just part of the user base at first, then later to the entire user base if the deployment is successful.

“While enabling organizations to develop software with more efficiency and speed, the DevOps process also dramatically expands risk through software exposure,” said Emmanuel Benzaquen, CEO, Checkmarx.

Beyond the Acronyms Lies a Secure SDLC

For many organizations, DevOps, CI, CD (and CD again) just amount to a lot of acronyms and words that are difficult to turn into their ultimate goal—a secure software development lifecycle (aka an SSDLC). As is so often the case, the Open Web Application Security Project (OWASP) provides a model for integrating security into any existing SDLC, which they call the Software Assurance Maturity Model. Applying this model in an organization is comprised of six basic steps, as follows:

• Assess: Ensure a proper start of the project by defining scope, identifying stakeholders, and spreading the word so people understand what you’re doing and why.
• Assess: Identify and understand the maturity of your scope in each of the 12 software security practices.
• Set the target: Develop a target score to use to measure against, to guide you to act on the most important activities for your situation.
• Define the plan: Determine a change schedule and develop or update your roadmap plan. It’s important to have a realistic change strategy in terms of number and duration of phases. Identify quick wins you can make early on.
• Implement: Work the plan by implementing all activities in this period, considering their impact on processes, people, knowledge, and tools.
• Roll out: Make sure that improvements are available and visible for everyone involved. Organize training and communicate the improvements to the team, then measure the adoption and effectiveness of the improvements implemented.

Successful Implementation of an SSDLC

It’s easy to say you’re going to implement a secure SDLC, using automation and integration. However, each of those six steps above takes time, energy, evangelizing, training, and much more. CIOs and CISOs seek ways to accelerate the maturity of their DevOps programs, but need help to get started. One way to accelerate that process is with expert services for software security deployment and automation.
Implementing automation into DevSecOps processes is a critical challenge for most organizations. An outside expert can work closely with organizations help advance the automation capabilities in their organizations and throughout their SDLC. Successful automation is just one part of implementing a secure SDLC. As outlined by OWASP in the steps above, it’s an ongoing process. Checkmarx provides customers with professional services, who share the essential guidance to develop and deploy software security programs with automation. Let’s get your organization off to a running start with DevSecOps.