For this year’s State of Software Security v11 (SOSS) report, we examined how both the “nature” of applications and how we “nurture” them contribute to the time it takes to close out a security flaw. We found that the “nature” of applications – like size or age – can have a negative effect on how long it takes to remediate a security flaw.
It can sometimes be a little challenging to figure out specifically how to address different vulnerability classes in Python. This article addresses one of the top finding categories found in Python, CWE 117 (also known as CRLF Injection), and shows how to use a custom log formatter to address the issue. We’ll use this project, which deactivates or deletes user accounts from the Veracode platform, to illustrate the functionality.
When it comes to application security (AppSec), most experts recommend using Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST) as “complementary” approaches for robust AppSec. However, these experts rarely specify how to run them in a complementary fashion.
For our annual State of Software Security report, we always look at the most common types of security flaws found in applications. It’s important to look at the various types of flaws present in applications so that application security (AppSec) teams can make decisions about how to address and fix flaws. For example, high-severity flaws, like those listed in OWASP Top 10 or SANS 25, or highly prevalent flaws can be detrimental to an application.
Are you fascinated with cryptography? You're not alone: a lot of engineers are. Occasionally, some of them decide to go as far as to write their own custom cryptographic hash functions and use them in real-world applications. While understandably enticing, doing so breaks the number 1 rule of the security community: don't write your own crypto. How do hashing algorithms work and what's special about password hashing? What does it take for an algorithm to get ready for widespread production use?
In volume 11 of our annual State of Software Security (SOSS) report, we uncovered some valuable nuggets of information about how you, the innovative developers of our world, can craft more secure code. For example, did you know that scanning via API improves the time to remediate 50 percent of security flaws by about 17 days, or that C++ and PHP languages have an alarmingly high number of severe security flaws and need greater attention?
It’s been a stressful year, to say the least, for the government and education sector. Government organizations were challenged with pivoting their operations to a digital model while schools were forced to decide between hybrid or remote learning programs for their students. The rise of digital operations has made application security (AppSec) more important than ever.
In our first blog in this series, Nature vs. Nurture Tip 1: Using SAST With DAST, we discussed how this year’s State of Software Security (SOSS) report looked at how both “nature” and “nurture” contribute to the time it takes to close out a security flaw. We found that the “nature” of applications – like size or age – can have a negative effect on how long it takes to remediate a security flaw.
On November 19, Veracode published new, official Docker images for use in continuous integration pipelines. The images, which provide access to Pipeline Scan, Policy (or Sandbox) scans, and the ability to access Veracode APIs via the Java API Wrapper or via HTTPie with the Veracode API Signing tool, make it easy to include the current version of Veracode tools in your automation workflow.
We recently released volume 11 of our annual State of Software Security (SOSS) report, which analyzes the security activity and history of applications Veracode scanned during a one-year period. Giving us a view of the full lifecycle of applications, that data tells us which languages and vulnerabilities to keep an eye on, and how factors like scanning frequency can impact your remediation time.
