Part Two: Secure Coding Urban Myths

In part one of this two-part series, we dug into a few urban myths about the security of open source code and trusting your favorite developer tools. While the myths are common, the reality is clear: taking ownership over your code with the right tools and methodologies means you’re creating applications that carry far less risk than ever before. Keep reading for three more common urban myths about secure coding—and how to go about changing them.

Myth 4: Using More Testing Types Will Just Lead To More Findings and Slow Everything Down, Causing Unnecessary Headaches

Reality: While it might seem like it’s adding extra work on the surface, having more than one testing type embedded into your development process saves time as you’re able to catch more flaws before the production stage. That means you won’t have to remediate a pile of vulnerabilities later on when it’s more of a hassle, and you'll have peace of mind knowing your code is more likely to pass policy checks. 

Although many teams decide to only focus on static analysis (SAST), dynamic analysis (DAST) can uncover flaws that are harder for SAST to detect. It finds issues within the environment and not just in the code itself – that’s a positive, as we know from State of Software Security v11 (SOSS v11) that exposing sensitive information through environmental features is a flaw existing in 60 percent of applications. 

Data from SOSS v11 also shows us that when organizations pair DAST with SAST testing, they are able to remediate 50 percent of security flaws 24.5 days sooner than other organizations that only use one testing type. Here’s why. 

Dynamic scanning is crucial to finding issues with server/deployment configuration and authentication, helping you evaluate how the application will interact with its environment to uncover flaws and exploits that may have otherwise gone unnoticed. Security issues feel a lot more real as DAST sheds light on those otherwise hidden threats; with DAST integrated into your security testing procedures, you have the ability to see just how an attack might unfold at runtime so that you can think more strategically. 

And while you’ll discover a higher number of flaws with DAST as it scans all applications and interconnected structures within an environment, you'll have the ability to remediate them quickly and focus on reducing your risk through prioritization. 

Myth 5: PHP Is a “Dying Language,” Which Means I Don’t Need to Worry About Understanding the Risks

Reality: Although PHP might’ve been dubbed a “dying language” after its creation in 1994, it is still alive and well. Despite different schools of thought (some may think it’s obsolete or will soon be overshadowed by newer languages), PHP powers nearly 80 percent of all websites built on known programming languages, and the latest version of PHP – version 7 – is used by nearly 60 percent of all websites running PHP. Some of the Internet’s biggest sites like Wikipedia, Etsy, and Facebook were built on PHP. PHP-based publishing platforms like WordPress and Drupal are extremely popular, and they often incorporate sophisticated functionality like e-commerce.

So, if PHP is here to stay, what’s the bad news? You can’t ignore the risk that it brings. We know from Veracode’s SOSS: Flaw Frequency by Language report that 53 percent of PHP applications have high and very high-severity flaws, with the most common being cross-site scripting, cryptographic issues, directory traversal vulnerabilities, information leakage flaws, and problems with untrusted initialization. When we look at the data in heat map format to compare flaw frequency by language, PHP definitely brings the heat as a big offender:

Despite being prone to risky vulnerabilities, PHP remains popular with developers and it likely isn’t going anywhere anytime soon. That’s because PHP is:

• Easy for beginners to learn, which means developers with some basic skills can pick it up quickly and start coding websites right away.
• Already popular within the broader developer community, with an established base of developers like you who bring a wide range of experience. 
• Streamlined to work well with open source code, enabling developers to complete coding projects in a more timely manner. 
• Ready to go with fundamental features like object orientation, packet management, and OS compatibility to facilitate modern web design needs. 

While PHP certainly isn’t dying anytime soon, it’s critical that you stay on top of the risks and exploits that it can bring – especially when leveraging open source components.

Myth 6: Cryptography Is Too Hard To Implement, So We Can Just Leave It up to the Security Team

Reality: Just like any other programming concept, learning the basics of cryptography without needing the skills of an expert mathematician or a cryptographer is possible. You simply need to familiarize yourself with cryptographic concepts, libraries, and best practices.

Cryptography establishes Confidentiality, Integrity, and Availability (CIA) in safeguarding data and communications, which is critical to the security of every organization. Cryptography shows up everywhere in our daily lives, from Wi-Fi security to your phone’s lock function and even key fobs for cars. Due to the criticality and complexity of any crypto-system, you need to, at a minimum, make sure your security is audited.

Cryptography is not going to protect you against all security mishaps, though. You still need to consider common application security issues like input validation, authentication, and authorization, and provide relevant mitigations.

Some cryptographic best practices include:

• Don’t roll your own crypto; a mere 17 percent of bugs come from crypto libraries according to a study from MIT CSAIL, and the rest are misuses or from developers rolling their own crypto.
• Most crypto primitives need a random number generator (RNG). Make sure your RNGs are cryptographically secure, which means it takes its source of entropy from underlying OS, such as /dev/urandom.
• For encryption, use only Authenticated Symmetric encryption, such as AES-GCM or ChaCha20-Poly1305 schemes. 
• For crypto-systems needing hashes, employ SHA2/3 family of hashes – not any algorithm from the MD family.
• When you need Message Authentication Codes (MAC), use HMAC (or hash-based message authentication code) with any of SHA2/3 family of hashes.
• Don’t store passwords or sensitive information in cleartext; instead use key derivation functions (KDFs) for storing passwords, such as Argon2 or Scrypt.
• Consider using elliptic curves (Edward Curves or NIST-approved curves) for any public key applications, such as digital signatures. 
• Poor key management is one of the most common cryptographic failures. Use a mature Key Management System (KMS), such as cloud-provided options from Amazon (AWS), Google (GCP), or Microsoft (Azure). For applications that demand the highest level of security, consider using Hardware Security Modules (HSM).

For more specific guidance and recommendations, read this Crypto series.