Creating Secure Coding Practices

As far in the past as I can remember, vulnerability remediation was always a significant part of my job, regardless of my role. Assisting development teams in remediating already known vulnerabilities could take up to 50-60 percent of all my time in any capacity. And I still cannot comprehend that when I open another software project that requested assistance with remediation, in my IDE, the code all lights up with warnings, suggestions, quality issues, and sometimes even errors.

My first instinct was to think, "How can we start talking about the security of the project when it has no basic code quality control?" So in time, I attempted to define what "basic code quality control" actually means, and I tried to create something like the old-school "You must be this tall to ride" initiative. With predictable results - that was still the "always no" classic security team’s approach. And there are already existing great resources such as OWASP OpenSAMM or BSIMM. Since then, I have created an essential list of the specific controls and tools that meet these requirements.

Everything I could find on the Internet so far requires software engineers to spend an enormous amount of extra time learning all those items and implies creating controls from scratch - which should not be the case anymore. In the past 10-15 years, modern software development has learned much about security and has embedded time-tested robust security solutions in popular modern platforms and frameworks.

That is proven by a fascinating fact - in the recent five years, whenever I was working with development teams to remediate vulnerabilities, it usually resulted in reducing code and complexity and not adding the security controls written from scratch but merely enabling what was already available as part of the platform or framework they used.

And now, there is only one bridge left to build before getting into the essence of wha I believe to be modern secure coding practices. Here it is.

Modern Secure Coding Practices Facts

My vision of Secure Coding Practices is all about the following.

Focusing on the Value to the Business

Most application security controls don’t need to be implemented from scratch. Modern frameworks and platforms already have security controls implemented by teams of brilliant engineers who have spent years improving and field-testing those controls.

As a result:

  • Most projects' goal is to enable the business, help the client, and not develop security controls from scratch. So unless we are developing a new platform or framework, we shouldn’t be wasting time and resources trying to reinvent the wheel.

  • It’s crucial, however, to follow rigorous hygiene on the project dependencies - everything from libraries to build tools (see the software supply chain issue). At a minimum:

    • Restricted to using only well-known and time-tested tools and libraries,

    • Followed by keeping dependencies up to date

    • And automated testing to ensure updates don’t break the application.

Employing as Much Help as Possible via Automation and Collaboration

The project should employ as much as possible help from both automation tools and human participants in everything from enforcing code style and testing coverage, all the way to pair programming and any other forms of code and design reviews. This philosophy is discussed in detail here: Preventing Application Security Issues. The best path there is by embracing Continuous Delivery, which is based on the experience of the modern software development community (and is the best way to reduce security issues I know).

Eliminating the Fear of Making Changes to the Code

There is nothing more important for the software delivery, for it’s quality and security, than overcoming the fear of making changes to the code.

Following the Modern Security and Development Practices

As of today, the best checklist on security controls that must be present in software I could find is OWASP ASVS. The trick is - it’s over 200 items that require an earnest effort to know and follow it. But the good news is - simply following the modern development methodologies and using well-known solutions takes care of most of the security controls in most software projects.

I, of course, can’t possibly pretend to be the one to teach you modern development methodologies. Try Dave Farley instead. But I can share the basics I learned the hard way by working on dozens of projects in multiple companies for over a decade.

My Approach to Writing Secure Coding Practices

This public and personal page is ongoing work, and I may be missing something. Secure coding practices that I create for my employers contain more detailed items, and I adjust those for the specific environment of the individual company (something like "Always use Artifactory for your dependencies and artifacts"). But it’s no secret what I am using as the base - so you can try it, too. Here’s the default logic I am using:

  1. Every security finding contains a CWE reference.

  2. CWE reference is mapped to Secure Coding Practices.

    • Using CWE in Secure Coding Practices allows embedding Secure Coding Practices in vulnerability reports and dashboards, all the way to use in custom IDE plugins.

  3. Secure Coding Practices are created using (and practices refer to it):

    • Company’s preferred (common) security solutions and the corresponding architectural guidelines

    • OWASP ASVS (also has CWE mapping)

    • The Twelve-Factor App (actually, as of recently I am mostly using "Beyond the 12 Factor App" by Kevin Hoffman)

    • OWASP OpenSAMM and NIST SSDF - these two are usually already embedded with the company’s Information Security Policy (and the derived standards), so the links in my documents typically lead directly to the policy portal.