Adding security as a key ingredient in any development project is hugely beneficial to any organization that develops software. Not only does baking in security-centric thinking and processes from the very start save significant costs over the entire lifecycle of the software, it also reduces the risk of systemic security flaws when they’re small, addressable problems instead of full-on dumpster fires. Key to this benefit is the use of automation and security tooling to reduce the workload on your combined teams and prevent the creation of testing bottlenecks and other delays.
Why Secure Software Development?
Why is security in software development important? Software is one of the most popular vectors for attackers, and supply chain attacks are increasing in both number and impact: according to Data Theorem, more than 91% of the 350 organizations surveyed in North America experienced a software supply chain attack in 2022. It’s imperative that any organization developing software makes and ships secure software – and that includes protecting the environments in which development takes place. Looking at the supply chain of the software, itself, is also absolutely critical.
In the (Almost) Beginning: DevOps
A very long time ago, software development and IT operations were two different teams, with two separate budgets, and quite often two diverging philosophies. This was ineffective for many reasons – and not just because it looked a bit funny on the organizational chart. Separate practices often meant one business unit didn’t always fully understand what the other was doing. DevOps was invented as a way to try and fix this: shared tools, practices, and even cultural and philosophical approaches. The Dev and Ops teams were happy – and so were executives, which is always nice.
Adding Security to Development and Operations
The DevOps methodology works well for most organizations But there are two problems. Firstly, existing security tooling and teams can’t keep up with the pace of software development; DevOps has created a development environment that works fast and iterates just as quickly. Secondly, as cybersecurity has become more important and gobbles up more budget, it has made sense to bake strong security into software development from the beginning.
Integrating security into DevOps so it’s included from the start of new projects saves cost, complexity, and friction later on. Good security practice is built into software development processes from the ground up rather than retrofitted or applied at a later stage. This reduces the number of architectural or systemic vulnerabilities, and saves on staff and budgetary resources that must be allocated when software flaws, misconfigurations, or critical issues are found later in the software development lifecycle after the software has been built and deployed.
All of this is possible using modern application security tooling and practices.
Rather inevitably, this new approach is called DevSecOps, abbreviating development, security, and operations into one slightly awkward portmanteau. Along with the organizational structure and processes established when companies adopt DevSecOps, there are domain-specific tools developers and AppSec practitioners can use to identify vulnerabilities, understand security posture, determine how to prioritize and remediate software security issues, and focus on team collaborations — as the name of the group implies.
Why and Where to Use DevSecOps Tools
Short answer: they need to be woven throughout the entire software development lifecycle (SDLC) — from design to runtime.
A typical DevOps pipeline involves planning, building, testing deploying, operating, and observing all of the steps, environments, and tools used in software development. And once those observations are in, it’s back ‘round to the start again. The snappier description for this is CI/CD – Continuous Integration / Continuous Delivery.
Because DevOps is a circular process of continuous development, feedback, and improvement, ensuring every stage incorporates security requirements is vital to successful and secure development throughout the SDLC.
Get your tooling right, and you will find it’s easier to mitigate potential weaknesses and vulnerabilities early rather than later on when the software is live and widely distributed. Good tooling does this, and – critically – doesn’t slow the development deployment, or monitoring of software.
Evaluate Your Tooling Through the Lens of the Five DevOps Principles
The DevOps Handbook identifies five core principles for the practice, using the mnemonic C.A.L.M. This stands for Culture, Automation, Lean, and Measurement, and can also be applied to selecting and using DevSecOps tools. The tools you pick have to fit with the collaborative culture your teams have hopefully already established. Automation keeps the overhead of securing software as low as is practical — but AppSec teams have to accept that certain things, like training and education, have limits to what can be automated.
Lean is also definitely appropriate. One example of Lean might be realizing that a certain tool is no longer the right one to use and it’s now time to evaluate alternatives.
Finally, measurement is critical on many levels when it comes to AppSec and software supply chain security tooling.
The First DevSecOps Tool You Need
We’ll call this early: If you’re starting from scratch, or looking to take a measured, programmatic approach to an existing DevSecOps program, the first thing on your shopping list should be a DevSecOps dashboard. DevSecOps dashboards are included in all cybersecurity tooling. When we’re talking about DevSecOps, this means SAST/DAST, SCA, IaC, secrets scanning, vulnerability assessment tools, and more. If you’re using separate tools for your application security assessments, you will need to find a way to consolidate data collected into one, unified dashboard. Application Security Posture Management (ASPM) was invented for this reason — to pull everything together so APpSec professionals have an easier, more streamlined way to visualize and manage their DevOps processes.
The reason we’re starting with dashboard capabilities is because it’s the primary way in which users (AppSec, development, and operations teams) will evaluate their environments. but not all tooling offers the same dashboarding capabilities. Beyond unifying all the data collected, an effective dashboard cuts through the noise of irrelevant information to allow the user to zoom in on the signals that matter, sorting outputs and automated logging into a view that makes sense to the individual user. When users can tailor their dashboards to their role, responsibilities, and workflows, what results is a context and a prioritized graphical representation of activities to work through.
Even if all the tools you’re using to collect security and operations data aren’t yet connected, dashboards will help you define needs and select (and upgrade or replace) tools as needs change. Even if you start small, by combining just a few tools’ outputs, you will have better visibility than if you’re trying to use disparate dashboards and non-normalized data.
But there’s another important reason why a consolidated dashboard is so important: it will allow you to be more targeted with your spending in the long term. Adding the data from existing tools into the dashboard provides a view of what bases you might already have covered with the technology you already have deployed. By continuously evaluating the outputs of your tooling, you now have an accurate picture of what you have to handle.
Another consideration, as we’ll look at next, is the culture, approach, and experience levels of the teams involved.
CI/CD: GitLab Vs. Jenkins
The second tool category is likely to be automation software for automating CI/CD pipelines. Jenkins and GitLab are some of the highest-profile tools for this purpose. Whoever you choose — or your teams use both — the outputs can be fed into an ASPM tool or other platform so the data can be consolidated, normalized, enriched, and correlated to give your DevSecOps team the greatest visibility into their CI/CD pipelines.
Jenkins is an automation server that can call on a huge ecosystem of plugins to automate the build test and deployment of software securely.
GitLab provides built-in version control and issue tracking, which is highly attractive to project managers.
Other options include Atlassian’s Bamboo CI/CD server, GitHub, Bitbucket, and Azure DevOps.
Protect Your Means of Production as well as the Software You’re Producing
It isn’t just about securing the software you’re delivering; it’s vital to secure your software delivery pipeline, too. Ensuring that the reusable elements you build into your software – libraries and APIs, for example – are secure and continue to be secure, is critical.
Good DevSecOps Teams Need Reliable Tools
It’s a no-brainer: automating elements of the “Sec” bit of DevSecOps and using the same principles of DevOps to do so, ensures security is integrated into software development and equips both operations and development teams with the ability to follow security best practices. By now, 2025, all security tools, including all DevSecOps tools available on the commercial market, should include the ability to automate. Whether or not the user turns on auto-remediation — a contentious subject among practitioners — or simply uses automation as a way to streamline low-level tasks like batch processing or alerting, automation is critical to solving software security risks.
Here are a few guidelines for automation:
- Automate scanning and testing: This ensures continuous visibility and monitoring and facilitates rapid response.
- Automate infrastructure provisioning and configuration management: Use Infrastructure as Code (IaC) tools like Terraform or Ansible to automate the deployment and configuration of secure infrastructure, ensuring consistency and reducing the risk of human error. This also enables rapid scaling and recovery in case of incidents.
- Automate security patching and updates: Implement automated patching solutions to keep systems up-to-date with the latest security fixes. This minimizes vulnerabilities and reduces the window of opportunity for attackers.
- Automate compliance checks and reporting: Integrate automated compliance checks into your CI/CD pipeline to ensure adherence to regulatory requirements and industry standards. This helps streamline audits and demonstrates a commitment to security best practices.
Once again, it should be noted that modern ASPM, software supply chain security, and DevSecOps platforms will include all these capabilities. So, if you choose to use point products (rather than platforms that offer native capabilities or platforms that allow you to use both native tools and integrations), make sure the platform has sufficient automation for the tasks your team needs.
Your DevSecOps Toolbox
If you’re stitching together point products or consolidating them into an all-in-one platform, the following capabilities should form the foundation of your DevSecOps program.
Two of the most common AppSec tool categories are Static Application Security Testing (SAST) and its partner, Dynamic Application Security Testing (DAST). Briefly, SAST looks at your application from the inside out, and DAST from the outside in; SAST tests the application at rest, scanning the source code before it’s compiled for potential security issues. DAST looks for vulnerabilities in the same application when it’s live and running. An example of this type of security testing might be a series of automated simulated attacks against the web front end of the app you’ve developed.
The Phased Approach
Looking at the development and operation cycles of Plan / Create / Verify and Preproduction / Release / Configure and Operate, it’s possible to assign different tools to specific stages across both the development and operations parts of DevSecOps. It’s worth noting, by the way, that not every DevSecOps team uses every tool category. Although the trend is steadily heading upwards, it’s worth being pragmatic about what your DevSecOps team can take on, as well as prioritizing tools that will make the most impact on the security of your development environment and final product.
[NB: this would be a good place to insert the DevSecOps diagram illustration]
Tools for the Planning phase
Planning, orchestration, and issue tracking should start in the planning phase, but will be iterated throughout the process. Threat modeling and security training also have a place here. Secrets scanning and management, a registry of trusted components, and protection for source code policies belong in this phase.
Communications and workflow tools are worth looking into at this point; Slack remains a favorite for many reasons, but Microsoft Teams and other corporate-type workflow and communications platforms are equally valid choices if they can be made to perform for your requirements.
Create Phase DevSecOps Tools
We’ve already talked about SAST and DAST, and this is where your application can and should be tested with these tools as it’s built. OWASP ZAP is a good choice as a starting point for DAST tooling for web apps. Also consider which tools are most appropriate for and compatible with the project’s chosen language — quite a few support only one or a handful of languages. IAST (Interactive Application Security Testing) provides vulnerability testing as it happens while the application is running; RASP (Runtime Application Self-Protection) should also get a mention here as tooling integrated into the product you’re developing to spot and stop security attacks.
API, mobile, and firmware security testing can all take place during this stage, too.
Verify and Pre-production Phases
During these phases, two general areas will need some sort of security checking. The first is Software Bill of Materials (SBOM) generation, checking that commonly-used third-party ingredients, dependencies, code, licenses, and so on are documented and – crucially – do not pose a security risk. While there’s been plenty of focus on open-source libraries as potential attack vectors following high-profile breaches in recent years, commercial packages – such as 3CX – have proven to be equally susceptible to compromise.
The second area is certification and management. Your SBOM is also one of these, of course, but there are also more immediate checks: PKI and certificate management, code signing, and the like.
At this point, your project is starting to cross from the domain of development (Dev) into actual operations (Ops), and this preproduction period calls for some additional active testing. This can take the form of penetration testing of the app and also fuzz testing, usually referred to as fuzzing. Aside from the great name, fuzzing is a fascinating topic in and of itself: a way to get the measure of a piece of software or hardware by throwing random inputs at its interfaces to figure out what is inside the box or provoke a non-standard reaction that can be used to achieve a goal – in this case, a security breach. Originally, this might have been a manual process, but modern fuzzing tools automate the generation and delivery of inputs for software testing.
Release Stage Tooling
As the project reaches open release, the tools in use become more operational. Cloud Security Posture Management (CSPM) is one example – a fairly established and self-described capability that provides similar security posture management for applications deployed via cloud services. Whether you have a standalone CSPM deployed or cloud posture management is integrated into your ASPM or AppSec platform, understanding your exposure during runtime is critical.
Automated compliance and API security and management should be automated at this stage.
Tools for the Configure and Operate phases
Technologies like Privilege Access Management (PAM), zero-trust network access (ZTNA), multifactor authentication (MFA), and Kubernetes are crucial for maintaining secure access. Your Ops team is already likely to have adopted these types of cybersecurity tools – Burp Suite, Tripwire, and paid solutions can be added to DevSecOps dashboards. The same goes for API and cloud workload protection, often as part of CSPM or as a standalone Cloud Workload Protection Platform (CWPP).
The DevSecOps Toolkit
There is no shortage of tools and integrations to choose from; the challenge is often choosing, managing, and maintaining these security tools as much as putting them to use. The variety, source, and usability of these tools present a complex but perfectly achievable challenge for DevSecOps teams, not least because they often have a power of three teams’ worth of talent, knowledge, and ability to draw on.
A central point of reference in the form of a dashboard provides you and your team with a view of potential risk, insights, automation, and context for all three teams.
For more information, and to see how OX Security can help you effectively protect your entire software development lifecycle, book a demo today.
)
