What Why How ???
What is it ? And Why is it important? In simple words, we are shifting or moving the Security aspect of any software (which is in development) towards the left of the Software development life cycle (SDLC). When we say towards the left we are talking about requirements , design and implementation phases of SDLC. In contrast to the traditional security assessment (Right Shift) we do it in the right side phases of SDLC like Testing Phase or Deployment Phase or even Maintenance Phase.
Yes, but why Shift Left (of SDLC) ? In short answer, Security by design is more robust. Shift left speeds up development efficiency and reduces costs ($$ , time and effort) by detecting and addressing software defects earlier in the development phases/cycle before they get to production (which decreases iterations of development cycles). Faster product delivery with higher quality can be achieved.
Waterfall model
Requirement -> Design -> Implementation ->Testing -> Deployment -> maintainance
Agile SDLC Model
Requirement -> Design -> Implementation ->Testing -> Deployment -> Review ---Repeat
But How ? Okay, in the Right Shift approach security considerations happen at the end of Product(software) development phases. So, in that case, vulnerabilities or flaws are identified at end of product development, and fixing those vulnerabilities becomes challenging like breaking of application due to regressions, sometimes we have to revamp whole subsystem of software in order to fix the issues (causes design change) and which in turn increases time and effort. So, Right shift introduces redundancy.
Okay, but How can we start with Left security?
While Designing an application, we should thoroughly define specification and required cases for the functionalities, also mapping functionalities with appropriate OWASP top 10 vulnerabilities and CWE (Common Weakness Enumeration) Top 25 so that it can be prevented. Once Design is ready validation of the design and the implementation (code), that means with Source Code reviews or to put it appropriately Secure Code Reviews (SCR), which classified as a SAST(Static Application Security Testing) Method or Whitebox or Glassbox Testing.
Before we start code review its important to understand the application behavior, for that we need to refer the various documents like requirements Doc, Specification Doc and API Doc and also take walk through with the concerned Application Developer. In SCR code reading, problem solving are two important skills to consider along with the top vulnerabilities awareness and CWE. SCR are of two types 1] Manual Code reviews 2] Automated Code reviews
1] Manual Secure Code reviews
There are two things, Primary code and Secondary code(third party dependency).
In Manual approach we focus on Primary code i.e we check for the code written by our own Developer, and secondly integration between Primary and Secondary code, for example it may be Oauth API intigartion or Some library or framework like Express.js etc.
Mostly we focus on the following
- Control or Logic Flow
- Data Flow Or Data Processing
- Sensitive Data or Hard coded values or comments
- Misconfiguration (e.g Improper object initialisation)
- Third Party Dependency (SCA)
SCA ( Software Composition Analysis) where we analyse and track any open source code(components) brought into a project. We track for the Components(Third party/Opensource library or framework) used, License of Component, version of the component or any known vulnerabilities associated with it if any. A software Bill of Materials (SBOM) is used as a part of SCA, its basically a inventory of items/components included in Product(Software) . Here, major concern is to detect and mitigate Supply chain attacks or any known CVE (Common Vulnerabilities and Exposures) or any 0 day Vulnerabilities.
2] Automated Code Reviews
In this type, tools are use to analyse and discover hidden vulnerabilities. These tools parses the source code and finds various patterns or signature in code and maps it to relevant vulnerability if exists. This is faster than Manual way, but its not as accurate as Manual approach, with this one can find simple or straight forward security flaws or (low hanging flaws) without much time, but this could give multiple false positive as well. Its recommended to validate the reported vulnerabilities Manually before taking any further actions, as it could be false positive or severity of issue is not correct.
So, What about Right Shift approaches, should be followed or not ?
Ideally, using both together yields better results, which gives 2 layers of security, though most of the software defects are discovered in Left approach. Think Left Shift as Primary or First layer and Right Shift as Second level, where residual defects if any exists can be found.
For more information,
Follow: Amos Koech