Code Security : Definition

A web search on “code security definition” will likely yield a result like this: the process of writing computer code aligned with the software industry’s best security practices. Fair enough, but what are these fabled “best practices?” Better still, how can developers even know how well they measure up to this standard? An underappreciated report answers both questions.

OWASP: Paving the Way

The Open Web Application Security Project is a foundation formed to promote secure programming practices. Its most famous project is the OWASP Top 10, a quadrennial ranking of web application security shortfalls. The heart of the OWASP list is a compilation of reports from the federal government’s National Vulnerability Database. Beginning with the 2017 report, the OWASP Top 10 added a survey of software industry security professionals to address up-and-coming security threats.

The Application Security Verification Standard is another OWASP project. With the ASVS, secure coding leaves the realm of platitudes and moves toward practical goals with verification methods. In 2009 the ASVS rolled out the first edition, its fourth and most recent edition was released in 2020 with revised definitions and a call to return to sound coding basics. Along with OWASP’s linked resources, the ASVP effectively serves as the industry’s secure coding handbook. With the ASVS in hand, an achievable code security definition comes into focus.

The ASVS: A Refined Definition

Good intentions are not enough in web app security, and therefore the ASVS spells out concrete ways to measure and verify security efforts. The report outlines three levels of application security:

Level 1 boils down to compliance with the OWASP Top 10 recommendations with verification by automated penetration testing. ASVS’s authors assert that this should be the minimum standard for any deployed web application.
Level 2 is the standard for any application that handles sensitive data. Meeting this benchmark requires periodic source code reviews by human beings. By providing concrete standards and matching verification methodology, ASVS Level 2 effectively defines code security in the modern era.
Level 3 is the recommended standard for applications dealing with national defense, high-stakes financial transactions, and sensitive medical data. As with Level 2, ASVS recommends a program of periodic source code reviews — and more of them. With Level 3, the group also calls for extra attention to a neglected aspect in modern software: architecture.

Architecture: Coders of the Lost Art

In the 2020 ASVS, the authors argue that the competitive pressure of the developer, security, and operations movement combined to squeeze out sound software architecture practices. The OWASP Top Ten 2021 brought empirical evidence of this trend: Insecure application design vaulted to fourth place. ASVS acknowledges that while web applications must adapt quickly, the app’s underlying architecture should evolve slowly. In other words, software architecture deals with an application’s design for its enduring mission.

The 2020 ASVS cites cryptography as a critical need for architectural foresight. In the DevSecOps pressure-cooker, cryptographic functions often end up scattered throughout an application. Noting that once-reliable cryptographic algorithms are now highly vulnerable, the report calls for centralizing cryptographic duties into a single swappable module. By modularizing their approach, developers can upgrade incrementally and avoid Hobson’s choice of top-to-bottom rewrites or band-aid on band-aid patching.

ASVS strongly argues that architecture source code reviews should become part of the continuous integration pipeline. The report’s emphasis on architecture highlights another theme: the essential role of humans in the verification process.

Verification: The Personal Touch Still Matters

The ASVS authors state that the majority of web app security risks require human verification. In the 2020 ASVS, the group highlights several vulnerable areas that must be part of every periodic source code review.

Cryptography Algorithms

Cryptographic failures were the second-highest vulnerability on the 2021 OWASP ranking, so it is no surprise that ASVS issues several stern warnings:

Use industry- or government-approved cryptographic algorithms instead of custom-coded efforts.
Verify encryption configuration settings in the periodic architecture review.
Ensure that the application stores personally identifiable information in encrypted form when at rest.
Avoid retaining unnecessary sensitive information.
Aim for 256-bit encryption.

Credential Storage

Automated testing is useless for finding credential storage vulnerabilities. Humans need to verify the source code, and this is one area where the ASVS lays down the law. It begins by mandating that applications hash and salt passwords in storage. Hashing uses an algorithm to convert a password into a string of numerals.

Determined hackers can crack hashing algos, but salting makes this trick exponentially more difficult. Salting a password happens by appending a 32-character suffix before the hashing phase. To add more security, each password should receive a randomly generated salt, and ASVS recommends separate storage for the salt phrase.

Finally, the ASVS acerbically notes that securely stored passwords mean little if a clever hacker can trick a harried call center worker into resetting a user’s account. Password reset protocols, including user notification methods, are another candidate for periodic code security analysis.

Input Validation

With modern web apps, input can involve users typing in a search term or a byte stream from another application. Input validation failures lead to a host of woes with cross-site scripting and injection attacks leading the pack. The ASVS argues that well-configured input validation could prevent 90% of such exploits. Towards that end, the authors supply these recommendations:

Program inside of a framework with built-in validation.
Sanitize all unstructured streams.
If the input is a URL, verify the destination against an allowed website list.

Authentication Architecture

In web applications, software components no longer reside on a single site. With apps that need cross-site communication, encryption is mandatory. ASVS also recommends enforcing the same rigor on permissions, with each component receiving the minimum permission level necessary. Scanning with a software composition analysis tool can flag out-of-date open-source components.

Access Control

Broken access control is the number-one web app security risk in the OWASP Top 10 2021, and the ASVS treats this peril accordingly. With broken access controls, users may interact with application data outside of their permission scope. ASVS suggestions for the scheduled security review include:

Manually verify access permission settings.
Ensure that the application checks permissions on a feature-by-feature basis instead of assigning blanket access based on a user’s role.
Verify the quality of the application’s logging capability to aid breach detection.
Ascertain that all access requests pass through a single upgradeable module.
Wall off user access to directory trees.
Test all methods of multi-factor authentication, including SMS text, authorization apps, and hardware keys.

SOOS: SCA Defined

A review of code security highlights the need for the best automation tools. Programmers may debate the best definition of code security, but the solution to software composition analysis is elegantly straightforward: SOOS. Scanning with SOOS compares every file of every dependency against an up-to-the-minute database of nearly 150,000 vulnerabilities. SOOS ranks security issues by severity, maximizing productivity for your coding team.

The best security review cycle is meaningless if a license compliance issue stalls deployment. Here again, SOOS is the answer. With SOOS, developers know the license status of every component down to the most remote dependency.

SOOS is the compatible and cost-effective way to keep the CI/CD pipeline flowing.