Nowadays we use the term “safe coding” or even “safe design” these terms are becoming more and more common among the creators of Secure development and Application Security.
However, for this to be completely true in our development processes we need to truly understand this term’s concept, and how Application Security is connected to them.
An article named, “A call to arms for devs: Get revolutionary about security as code” Daniel Cuthbert, defends that we must focus not on the attacks but on how to defend our software, which we fully agree, because in general, if we focus on attacking we are not effectively solving a problem, we are just masking a solution.
Understanding the process of Secure Development software
In many cases we noticed that by trying to implement a secure development process, many teams forget to understand what the concept of making secure development really is. The truly understanding on this process can help you and your team to implement security in your applications.
One of the main concepts for those who are willing to implement security on their development process is shift left, it is based on the displacement of security initiatives from the final stages of the process to their earlier stages.
This movement helps, every time, to identify coding fragility in a faster way, providing to the development team the opportunity to start coding correction earlier.
Check your development
The OWASP SAMM is a maturity model kept by OWASP and its objective is to help companies willing to implement a Secure Development Process in a more efficient manner. Even if some people might think that SAMM is a more complex model, we can help by posing some questions that will help evaluate the maturity level of your actual model of development quickly, and then having a clearer idea on how SAMM works, you can adjust your model.
- Requisites – At the moment of your software construction, Is it necessary for your team to weigh the needs of security and privacy?
- Design – Does your team when initializing a new software project take the necessary actions to identify threats on which your software might be exposed? in a more direct way, do they do threat modelling?
- Coding – During the creation process of your code, Is there any type of code validation, such as, Code Review?
- Tests – While running application tests, are static test or even requisites of security identified?
- Operation – While operating your software, Is a Pentest done to assure that the application is protected?
If you answered NO to the majority of these questions, it means that your secure development process is still in a low maturity level, and needs to be strengthened with the best practices in Secure Development.
It is natural that most companies concentrate their security efforts towards the end of their development process. This practice makes the project even more expensive, because it takes to the last parts of it to check for vulnerabilities that should have been done on earlier stages. A late discovery of a vulnerability forces development teams to redo a task on top of something that should have already been secured.
When a shift left concept is implemented we have the chance do find out these vulnerabilities at the development cycle early stage, therefore there is a chance to apply corrections in advance, having an economy in all the process.
Threat modelling, the earlier the better
Doing THREAT MODELLING can help your development team to build a code on base of a possible threat list that can be exposed from your software. Being aware of these possible threats, developers can look for solutions, that prevented identified vulnerabilities to be present on the code being implemented.
However, many are still in doubt on what is a Threat Modelling, and the best definition was given by Adam Shostack on hi book “Threat Modeling: Designing for Security” where he describe the topic as:
“Threat modeling is the use of abstractions to aid in thinking about risks.”
If we think about his affirmation we understand that Threat Modelling is mainly Identify and Prioritize risks on which our application can expose, and this is what we need to prevent.
Think about your Security Requisites earlier
The earlier your vision on security requisites is, the better. When we start thinking about Security on its early stages of the Development process, we can easily evaluate possible solutions to be used to make the software more secure. Thus the importance for the requisites of security to be evaluated as soon as possible, one possibility is to use the OWASP ASVS.
When you have established your requisites, set them as priority inside your solution plan, because during coding they will be essential to assure software security.
Evaluate, measure and improve your process
A secure development process needs to be constantly evaluate.
This evaluation needs to be based on data, and information that can be relevant. however, only data and information are not enough to deliver the best result to the process, these data must be evaluated by someone with a strong security background to give the best evolution possible.
Whenever possible make a code review
It has been said that application security is more about processes and cultures rather than keeping a bigger and always updated team of developers. To assure that an application is secure it is necessary a few things, some of processes, others on culture and some other things on automation. However, one of the steps that can bring an extreme result to security is Code Review.
Keep in mind that secure development process is not and cannot be confused only by a code review on applications, it involves many other steps that need to be observed.
Monitor what is yours
After you have better structured your process, or even, thought on how it could be better, it is essential to assure that the application is secure, in case something goes wrong, like data leakage or even a code, it is necessary to have a monitoring mechanism.
Monitoring your code or your data is important because it guarantees a faster response on leakage, and it is important because only 13% of leakage are seen by the internal team of a company, a good solution is to adopt a monitoring tool such as Data Leakage Discovery, offered by AXUR a company specialized in monitoring and we believe that this article can help.
No loose ends
When we observe companies that have implemented the shift left concept on their development processes we noticed that they are far more effective on identifying and validating vulnerabilities on their codes. This also guarantees to these companies the necessary knowledge to evaluate the cost to correct these vulnerabilities inside their projects, having in a general way less costs.
However we observed that the desire for solutions to be delivered earlier overweight the secure development process that many times can’t be accounted for by the companies. That is way the concept Security as Code has a great importance inside the process, though it helps companies to create a more efficient, secure and robust delivery structure.
The vision of this text is to present you a possibility and an opportunity to think on how your process is structured and to point out a new beginning on this journey.