Five DevSecOps/Application Security Lessons to Learn from Recent High Profile Security Breaches

The Current State of DevSecOps

The frequency of public, high-profile security breaches has increased at an alarming rate. These breaches are having a more visible direct impact on everyone all over the world. A few high profile examples that you may have heard of recently include:

There is increasing pressure for governments to implement stronger cybersecurity measures such as the latest executive order for securing the software supply chain and sanctions against nation-state threats.

How can we mitigate these kinds of threats?

While it may not be possible to completely prevent these breaches, we may be able to increase the odds of successfully defending these threats. Using the Onion Model of Defense as a model, application developers and stakeholders can directly contribute towards securing the application layer. Application layer stakeholders can work together with the other participants, across all of the other layers, to build a robust defensive model towards security.

Source: https://en.wikipedia.org/wiki/Information_security

Practical Lessons to Live By:

Cybersecurity is everyone’s responsibility:
1. Cybersecurity is not solely the responsibility of the Information Security roles in the organization. Every individual and team in an organization regardless of their role must implement information security hygiene in their everyday practices. This even extends to everyone in their personal lives since security best practices are required in the increasing technology-centric world that we live in. In a professional setting cybersecurity awareness training needs to be mandatory including ongoing education.
Software Supply Chains must be secured:
1. From the recent executive order that we linked above, we can conclude that there is growing awareness that securing the software supply chain is as important as securing the supply chain of other critical national interests. At the application development layer, it is necessary for teams to have a reliable bill of materials. It is also necessary to have continuous scans with actionable findings of open source and other software dependencies used by your projects.
It is best to provide early feedback to developers:
1. It is too late to provide developers actionable feedback on the quality and security aspect of their code when it is done close to the release. Ideally, developers need to be provided with early feedback starting with their IDE itself in the form of static analysis, linters, and other quality checks which have low overheard or can offload the analysis to a remote / cloud-based service. With this kind of iterative feedback, it is less likely for developers to miss critical security issues in their source code.
Embrace DevSecOps or, inject security in every part of the process, starting first with the CI/CD pipeline:
1. The idea of DevSecOps is not only to empower developers but also to inject security universally. In the previous lesson, we talked about providing feedback to developers during the development process and even some results directly in their IDEs. However, it is also necessary to implement different application security checks as part of the CI/CD pipeline including acting as a quality gate before code can be merged from feature/bugfix branches. Ideally, there should also be different thresholds for these checks including more strict ones when gating the software release process.
Shift Left Paradigm:
1. We recently wrote a blog post describing how we assisted one of our customers in implementing a shift left strategy for their enterprise organization to empower developers and stakeholders. This is a good example of how Addteq architected an effective and pragmatic solution by connecting discrete application security tools to automatically run application security checks as part of the CI/CD pipeline. The achievement was also assisting the customer to implement a major cultural shift in their approach towards embracing DevSecOps for improving their application security process.

How can Addteq help?

Addteq can assist your organization in embracing the benefits of DevSecOps while minimizing the risks associated with application security pitfalls. Addteq has a two-pronged approach to injecting application security as part of your CI/CD pipeline:

Fixing fragmented application security tooling and process.
1. Most organizations have various application security scanning tools from different vendors for SAST, DAST, Open Source, Container scanning, etc. They are content with the results produces by these tools. However, in most cases, the scans are performed infrequently and close to the release or worst, post-production release. Development teams feel that the feedback from the scan results produced by these tools is too infrequent and late causing productivity issues and becoming a source of friction for the software delivery process.
2. Addteq mitigates the fragmentation by architecting the CI/CD pipeline to automatically trigger the scan for all of the various tools for every code change including gating merge/pull requests. Some of these scans can take minutes or hours so it is not ideal to block the CI/CD pipeline.
3. Addteq’s approach ensures that the scans are triggered asynchronously in the pipeline while still ensuring that the feedback for actionable findings is automatically reported to the development team’s backlog in JIRA.
4. The findings automatically reported in JIRA are for the scans related to the release candidate. These findings have SLA (Service Level Agreement) associated with them to ensure timely mitigation and visibility.
5. Addteq’s solution includes a rich dashboard with KPIs and quality metrics aggregated across the results from the various application security tool findings. Development teams, managers, and executives can monitor the application security health of their projects in a convenient aggregated dashboard instead of having to check metrics scattered across multiple tools.
Clean slate application security process implementation.
1. Addteq implements the same solution outlined above minus the application security tools fragmentation. We recommend and implement Gitlab in order to empower organizations to eliminate the need for most other application security tools. Gitlab is not only the leading solution for source code management and modern CI/CD pipelines but it also includes SAST, DAST, Container, and Dependency scanning, Secrets Detection, and License Compliance checks, all within the Merge Request CI Pipeline. Gitlab includes Security dashboards at the project, group, and instance level. Development teams can avoid the context switch required when dealing with multiple application security tools and instead rely on the streamlined solution provided by Gitlab.