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.

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.

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.

Software development and security often have separate challenges and concerns. Developers are worried about pushing software to production in a timely manner. Security teams worry about the security of the code being pushed. Veracode offers a solution that meets the needs of both sides. On Peerspot, where Veracode is ranked number one in application security, users discuss how Veracode enables them to build an advanced application security program.

In the realm of cloud security, public sector agencies have a lot on their plates. From keeping up with the barrage of constantly emerging security guidelines (see below) to the ongoing demands of maintaining software security, the pressure on the government to lock down cybersecurity is immense.

It has officially been one year since the release of the Biden administration’s Executive Order on Cybersecurity, which outlines security requirements for software vendors selling software to the U.S. government. These requirements include security testing in the development process and a software bill of materials for the open-source libraries in use so that known vulnerabilities are disclosed and able to be tracked in the future, among other things.

Most software today isn’t developed entirely from scratch. Instead, developers rely on a range of third-party resources to create their applications. By using pre-built libraries, developers don’t need to reinvent the wheel. They can use what already exists and spend time on proprietary code, helping to differentiate their software, finish projects quicker, reduce costs, and stay competitive. These third-party libraries make up part of the software supply chain.

Ready to secure government applications? Start with Zero Trust. Trust is the foundation of successful relationships. We want to trust our friends, companies, government, etc., and be trusted in return. But, sometimes mistrust better serves us. A few years ago, the cyber world adopted an approach to security known as trust-but-verify. A simplistic approach, it delivered innovative digital services to consumers – securely and efficiently.