Wow, after a few years of coding I went to a conference organised by OWASP. I always liked the ability to find a leak or exposure and even sometimes make fixes for it. But then again, i’m a software engineer and that’s what we’ll do, create and fix code. Or not?
After the first keynote they’ve had my full focus, already i was interested in the security aspect but after this the curiosity was burning inside me. I want to know more, no one ever told me there was this world of people which actually care about security. Whether is was pen-testing or baseline scanning, even the OWASP top 10 becomes a lot more interesting when you’ve been to such a conference.
But then the most embarrassing moment of my professional career happened. I went to a speaker after his presentation and start asking questions about the topic and the answers had me more riddled then it provided answers. Which language was that? I was programming for quite a while now and I didn’t understood a word he was saying.
The talk was about implementing ZEST scripts (https://www.zaproxy.org/docs/desktop/addons/zest/) which are triggered by OWASP ZAP (https://www.zaproxy.org/) throughout a pipeline (https://plugins.jenkins.io/zap/). As a software engineer I was stunned by the possibilities which I saw, a whole new era of development has started (at least in my mind). But then when the man started answering my questions i’ve heard terms I’ve never heard before or never had a deep-dive over it. Shameful as it was i started questioning him about what he meant and how that relates to the presentation.
Then it made more sense, although i didn’t asked him all of my questions because it just were to many. A co-worker filled me in which was from Security and privacy with some JAVA programming skills. After this really enjoyable conference i’ve started talking to software engineers and testers about security topics, and even the most senior members only know OWASP of the top 10. When I started about OWASP ZAP, they had no clue. I looked in the codebase and I mostly saw code (quick)fixes for production issues rather then a pro-active code improvement based on a vulnerability scan.
That’s why I made this post, developers/ software engineers/ software architects / DevOps engineers which are starting their career but also which already hold a certain position as a experienced developer need to know the basics about security so they actually are aware of the output from their code.
I managed to implement a owasp dependency check plugin for gradle. This is done on a example spring boot page from the pivotal website and cloned from github. The only adjustment I’ve made to it was adding the dependency check plugin and ran the associated gradle task. A report was generated and after reading the possible configuration items i clearly needed some answers. This was a solid report but I couldn’t answer any questions about the report, and that were still my own questions.
Then my hunt for answers started and I guess this is a good starting position for more knowledge about security but in my opinion also about the application you’re working on!
Start with the source
Let’s start where the knowledge is saved, the NVD. The National Vulnerability Database, which is hosted by the American government. The dependency check plugin first downloads the entire database and then scans the dependency.
In this NVD are CVE records stored which provide information about the CVE, you could also look this up on the NVD website among other websites. A CVE means a Common Vulnerability and Exposure, which holds a record of information about the found vulnerability. You can search for vulnerabilities richt here: https://nvd.nist.gov/vuln/search.
This information is used to classify the CVE and states what they did to find it on an abstract level. There is also a score property of a CVE. This is called a CVSS, Common Vulnerability Scoring System, which can help you in your choice to manage priorities. More information on how this vulnerabilities metric system works can be found here: https://nvd.nist.gov/vuln-metrics/cvss .
There are two versions of these metrics, version two and three. The difference is in the number of severities. Version two has three: low, medium and high where version three has five: None, low, medium, high, critical. Personally I’ve usually seen version three of the metric system.
On the page of a certain CVE there is also more information which helps explain the risk of the CVE. Therefore it can be helpful in which direction you can start looking if you must fix such an issue.
The NVD is free and as it says on their website, it’s maintained by the US government. The NVD updates regular but the process is rather slow. If today a CVE is reported, it could take some time before the NVD is updated. This is because the CVE is analysed before it is successfully added tot he NVD. This is to ensure no false exploits are in the database. There are commercial companies which maintain an database of their own which are updated much faster.
I dare you after reading this post to make a baseline scan of your codebase without adjusting it and see which CVE’s are found. OWASP ZAP and BurpSuite are used for that purpose among others.
In some cloud environments this kind of scanning is actually already integrated as I migrated a project to the cloud and suddenly there was a broken pipeline due to security issues. Great job there!
Then I’ve mentioned the database, the CVE and it’s score but when do we use it and how?
Now is the time to introduce the term SSDLC, Secure Software Development Life Cycle. A term which I think is still a bit vague but it does cover it’s contents. It’s an abstract term for the whole process of developing software. But from a lifecycle start till the lifecycle end there is security written all over it. More information about this can be found on the github repo of a co-worker: https://github.com/brampat/security/tree/master/defense/secure-coding/ssdlc.
In the flow of SSDLC are a number of steps which are import and most import are the ones that most people forget. Security is most forgotten in my experience in the Requirements phase and Decommissioning phase.
Why the Requirements phase?
In Scrum terms I would say when an epic emerges out of a brainwave session, think of security. For instance, if somebody is able to enter anonymously to a part of the application where you at least require registered customer rights then you’ve got a problem. That’s a thought you could have in the Requirements phase as a Risk Assessment as you can address that in the Design phase and it will be build in the Build phase.
Why the Decommissioning phase?
However when a application is meant to shutdown permanently or is not being used and further maintained, that’s where a lot of bad choices come in. When an application still runs but it’s forgotten, that is a key choice to decommission it. The software running after a while turns legacy and maybe even has exploits in it which are discovered and the NVD updated.
That means you’re giving a golden ticket to the finale for hackers, they still need to do the work but the door was held wide open. It still happens to me that after a while on a job there is this little application, or sometimes even a “test” application which runs on production but nobody is mentioning it during work meetings but when I asked about it, it’s a test application and wouldn’t hurt anybody. That makes me wonder why haven’t you deleted it yet? Small action but could prevent a lot of bad publicity.
For example, some log framework I recently discovered had a RCE possibility. A RCE is a Remote Code Execution vulnerability, which in this case means if it’s discovered by hackers it is literally possible for them to execute custom code on your production machine. That’s what old applications which are still running could leave behind, vulnerabilities!
This are some of basic security concepts which I think can help understand the impact of developing applications when they reach the production stage. There are a lots of tools and tip available on the internet which suit your needs, Open Source but commercial as well.