Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

JavaScript is a programming language based on prototypes instead of classes. When a new object is created, the features of the prototype object are inherited – this includes arrays, functions, and even class definitions. The new object can also act as a template for other inheriting objects, transferring its properties, and creating the prototype chain.

The global pandemic and more recent geo-political events have brought an even greater focus on the threat of cyber attacks on individuals and businesses. Even as global lockdowns and restrictions on movement have eased, many organizations have not adapted to remote or hybrid styles of work. The reality that most of the workforce now operates outside a perimeter that can be controlled creates greater opportunity for scammers, hackers and the potential for cyber attacks than ever before.

Static Application Security Testing (SAST) is one of the principal techniques for assessing the source code of applications to detect possible vulnerabilities. SAST enhances application security during the early stages of the development life cycle and plays an important role in shifting security left. However, there are quite a few myths that are often associated with implementing SAST security tools. Let’s run through the big three.

It is not hard to set application security goals. Security teams want to reduce risk. Developers want to quickly meet the requirements of security policy and hit deadlines. Executives want growth within their risk tolerance. What is hard is defining an appropriate level of risk and measuring whether your AppSec program is efficient, effective, and returning expected outcomes based on your investments.

Most developers don’t learn about secure coding in the college IT programs. And once they join the workforce, they often don’t have the time to learn about secure coding. The responsibility of training developers in secure coding best practices usually falls on security practitioners. Security practitioners are notoriously overworked, often lacking the bandwidth to train developers. Organizations are thus turning to AppSec learning experiences built specifically for development teams.

The continuing escalation in cyberattacks on large corporations, coupled with an acceleration of digital transformation, has forced organizations to reassess their security strategies and infrastructure. This escalation has driven growth in the adoption of zero-trust application security and compliance. The zero-trust approach means that no devices or software should be trusted by default, even if they have permissions and previous verification.

A few months ago, we released our 12th annual State of Software Security (SOSS) Report. In our announcement blog, we noted new application development trends (like increased use of microservices and open-source libraries), the positive impact that Veracode Security Labs has on time to remediate security flaws, and the increased use of multiple application security scan types. But what we have yet to dive into is the security flaws we found in different programming languages.