Secure Coding in Five Steps?

There's still a shortage of education in cybersecurity. There's still a lack of workforce generation in this area. As reported in the (ISC)² 2022 Cybersecurity Workforce Study, there is currently a "worldwide gap of 3.4 million cybersecurity workers". On the software development side, many professionals are unfamiliar with the subject and deliver products that sometimes don't even undergo (at least adequate) review. Secure coding and secure code review, or better yet, an entire secure development cycle, should be taught to developers from the beginning of their careers. While their work is usually supported by other teams (such as one specifically for security), security-savvy developers can contribute early on to making their products high quality and consequently secure. We must seek to leverage existing resources and create methods that contribute to their training. In this post, we focus precisely on a simple approach recently suggested in a research article.

While roaming the Internet looking for a topic to round out a short series of five posts regarding the concept of "secure code review," an article called "Secure Coding in Five Steps" caught my attention. (Incidentally, the posts in that series are "Secure Code Review," "Go Over and Practice Secure Coding," "Indispensable Manual Code Review," "Code Quality Must Include Security" and this one you're currently reading). Published in mid-2021 by Zeng and Zhu in the Journal of Cybersecurity Education, Research and Practice, this is a free and open-access article that you can find and review in full at digitalcommons.kennesaw.edu.

What the researchers in the article referenced here intend to do is to bring about an improvement in this situation. They start from the fact that it's from the beginning of the development of software products that trainees and professionals must think and act in terms of security. They present a five-step approach to learning that is more suitable for students, less complex, and that motivates them to practice secure coding. "The long-term goal is to educate students on the right mindset, necessary knowledge, and skills to develop secure software," say the authors. In their research, they didn't merely share theory but put it into practice with their own undergraduate and graduate students in their computer and software security course. Let's take a look at each step with its background and what these researchers' methodology was like in action.

Although we could speak of a "step zero," the researchers didn't name this first procedure. Perhaps because it's not focused on secure coding per se. What they did initially, before the first step, was to give the students a broad landscape in secure development, using as a reference the Microsoft Security Development Lifecycle (SDL). This is a set of 12 practices that promote secure software development (practices closely connected with what we do at Fluid Attacks):

This step is aimed at gaining knowledge about common security vulnerabilities. The CWE Top 25 most dangerous software weaknesses and the OWASP Top 10 most critical web application security risks come into play. The authors introduced these lists (in addition to the Common Vulnerabilities and Exposures, CVE) to their students. They then selected three types of vulnerabilities (i.e., Cross-site scripting, SQL injection and Unrestricted upload of file with dangerous type) and explained in depth their characteristics, exploitation mechanisms, potential impacts and detection and remediation methods. Afterward, to vividly illustrate all this, the researchers used ShareAlbum as an example of software with these vulnerabilities. As part of their active participation, the students had to review the other vulnerabilities on the lists, choose two and explain them briefly to their classmates. In addition, the students were given small pieces of code from ShareAlbum to detect and remediate vulnerabilities of the three types initially discussed.

This step is aimed at acquiring skills in security testing or vulnerability identification. The authors recognize manual code review as indispensable and the benefits of mixing this method with automated tools (for their scalability and speed). For this reason, they assigned small groups of students to detect errors in the app's code by manually following a checklist (adapted from the OWASP Code Review Guide) and using a free SAST-type tool, to which they were duly introduced. The list of security issues that the students were able to assemble included errors such as improper input validation, improper authorization and information exposure. In their exercise with the automated tool, the students were made aware of its shortcomings, such as the existence of false positives and false negatives, and educated in their identification and solution. After that, they were able to practice recognizing and reporting the false positives provided by the tool in its list of identified errors.

This step is oriented to the prioritization of vulnerabilities. The researchers shared with their students that remediation of all vulnerabilities can be costly, so they should be prioritized according to different attributes. It will always be more beneficial in terms of risk and resource management to strive to close some vulnerabilities before others. Therefore, the students were introduced to the Common Vulnerability Scoring System (CVSS; at Fluid Attacks, due to a couple of defects in this system, we modified it slightly to become "CVSSF"). The authors taught the students the use of metrics (e.g., exploitability and impact) for calculating CVSS scores and ranking and labeling vulnerabilities. Then, the students used the CVSS calculator for the vulnerabilities they had previously detected in the app. From there, they prioritized vulnerabilities according to the scores obtained and provided the top three errors to be remediated in the next step.

This step is aimed at vulnerability remediation and risk mitigation. The remediation suggestions provided by the CWE and OWASP websites and the SAST tool were considered. The authors took the three vulnerabilities they used as examples and presented the students with their step-by-step remediation in ShareAlbum. Next, the students took their top three security issues or errors from the previous step, discussed remediation strategies and then applied them as code changes. Finally, they performed another code review to see if those modifications had been effective and if they had resulted in new vulnerabilities, which would need to be remediated.

This last step is oriented to the reporting or documentation of results. Recognizing the frequent use of standard report templates in industries, the researchers put together a template based on "the OWASP secure coding report items and the MITRE secure code review sample." The students had to submit a report following the template, which had nine items, including review dates, code modules reviewed, checklist and tool used, vulnerabilities identified and the top three of these (each with details such as name, description, location, severity and remediation strategy), among others. (For example, you find all that kind of data when you receive reports in the Fluid Attacks' platform).

As I was reading this article, it seemed to me that it was very much in line with what we have offered in previous secure code review posts and, in part, our way of working at Fluid Attacks in software assessment. I don't know if this five-step approach is the best way to introduce software developers to secure coding practices and skills. Still, it is definitely a worthwhile approach (the researchers say they are improving it further, for example, by broadening the spectrum of programming languages used). I thought it was a good idea to start by giving students a "big picture of secure coding," exposing them to the many resources available (other examples: OWASP SAMM, SAFEcode and CERT standards), as well as giving them lots of examples and, above all, "hands-on opportunities." From universities and companies, we should encourage learning in secure software development with proposals like this that serve as part of a preventive strategy against today's growing cyber threats. We invite you to review Zeng and Zhu's paper thoroughly to get more details about their suggested approach.

Now, if you are looking for support for the development teams in your organization by security experts, do not hesitate to contact us. At Fluid Attacks, we offer Secure Code Review within our Continuous Hacking service that mixes automated tools with expert intelligence to detect vulnerabilities in your software. If you want a first taste of our cybersecurity capabilities, we invite you to enjoy SAST, DAST and SCA techniques with our automated tools in our 21-day free trial.