Back at the beginning of August 2020, we wrote an educational article explaining the difference between DevOps and DevSecOps. While our article was informative and gave the background and history of DevSecOps, it may have left you wondering how you move from a DevOps mindset to a DevSecOps mentality. Github just published an informative guide to moving to DevSecOps.
The Github article makes a good point and clarification about shifting left and adding security to your development process. Instead of calling it DevSecOps, we should be referring to it as Continuous Security. From the article:
Continuous security draws a parallel to continuous integration and continuous delivery: you should continuously integrate security into your development process as well.
What this means of course is that in order to practice DevSecOps, development teams need to implement controls earlier, including security controls. The article makes a good point that when you’re shifting left, yes that means changing your development practices, but it also applies to security itself and changing how you think about security. As the article says:
It’s critical to prevent breaches before they can affect users, and to move quickly to address newly discovered security vulnerabilities and fix them.
One last note about Github, the site presenting this new article on DevSecOps. Github, of course has become a popular way to reduce development time, by enabling access to a repository of code. When using Github, it’s important for organizations to treat it like they would when using any other cloud based service. Security should remain at the top of mind for how they access the Github ensuring their users remember good password practices, and the right access permissions. For code they are taking from Github, they should also likewise treat it the same as any code they’d use in their production systems, it should be tested thoroughly for security vulnerabilities, and should also be well protected while it’s running in production with application security.
K2 Cyber Security provides deterministic runtime application security that issues alerts based on severity and includes actionable alerts that provide complete visibility to the attacks and the vulnerabilities that the attacks are targeting including the location of the vulnerability within the application, providing details like file name and line of code where the vulnerability exists.
K2 can also help reduce vulnerabilities in production by assisting in pre-production testing and addressing issues around the lack of remediation guidance and the poor quality of security penetration testing results. K2 Cyber Security Platform is a great addition for adding visibility into the threats discovered by penetration and security testing tools in pre-production and can also find additional vulnerabilities during testing that testing tools may have missed. K2 can pinpoint the exact location of the discovered vulnerability in the code. When a vulnerability is discovered (for example, SQL Injection, XSS or Remote Code Injection), K2 can disclose the exact file name along with the line of code that contains the vulnerability, details that testing tools typically are unable to provide, enabling developers to start the remediation process quickly.
Rather than rely on technologies like signatures, heuristics, fuzzy logic, machine learning or AI, K2 uses a deterministic approach to detect true zero-day attacks, without being limited to detecting attacks based on prior attack knowledge. Deterministic security uses application execution validation, and verifies the API calls are functioning the way the code intended. There is no use of any prior knowledge about an attack or the underlying vulnerability, which gives our approach the true ability to detect new zero-day attacks. Our technology has 8 patents granted/pending, and has minimal false alerts.
Get more out of your application security testing and change how you protect your applications, and check out K2’s application workload security solution.