The business loves this - features get pumped out faster than the competitors.
There's plenty of checks and balances already in software processes to stop the technical debt from getting out of hand, including code reviews, feature testing automation, and whatever is needed to be considered 'done-done'. However, there is a perception in the software industry that the software security checks and balances get in the way and slow things down.
That's often because it does. Manual security testing can take weeks to execute, and months to schedule. Connecting a commercial security tools' API into the CI/CD tool itself take weeks, only for the API to change again and things break. It can then often take months to schedule that project to connect the tools - only for the business to switch to another tool on the top right of Gartner, and the build/release integrations are back to square one
Even when the team gets security tests, it can be hard to understand what the issue is, or how it should be fixed. Furthermore, knowing the priorities of what can slide into the release, and what must be fixed immediately, adds further strain and time to the software team.
Security tests slide, releases go out without security testing due to business demands. Then it all comes to a head when the security teams get to run a full security testing exercise and suddenly there's 1000's of security tickets that hold up feature tickets and releases.
There can be nothing more frustrating than a security issue being flagged up months after the release, only for the investigation to realise there's been 10's of other changes applied on top of the original bug. This means the fix is so much harder, and a bunch of other features will need to be re-tested before we get to 'done-done'.
Even when the fix is in, 'done-done' requires the security team to confirm the fix, which introduces the same delays that caused the problems in the first place.
The answer can be simple - wrap as much security tooling and testing into the DevOps release processes as possible. This way security checks are automated, and issues are found quickly so they can be resolved quickly - before more code is piled in on top. Releases are not delayed on security teams or manual security tests.
Actually doing this is not just so simple. As mentioned, you can hook in a commercial tool, using APIs, and get a measure of security automation during the DevOps builds. What can hold this back is the realisation that one tool doesn't cover it. That application security tool won't cover cloud configuration checks, container checks, network checks, and so on. There's plenty of issues that are found by open source tools and scripts that are desirable, however many do not have API support and would take further time to integrate into DevOps tools.
Furthermore, there's plenty of security issues that are typically not found by off the shelf security tools. Those business logic aspects of the application that needs context. Should the Admin user be able to approve those mortgages? Should the junior user be allowed to download the entire customer list from their search feature? These checks are typically manual, or are scripted by the dev or security teams, but won't have an API, etc.
Add to this the other tasks typically involved in a security operation, such as marking false positives, duplicates, creating reports, interacting with Jira, Slack, e-mail, etc., flagging when new issues are discovered and old issues fixed, and the 'quick security tool integration with CI/CD' explodes into a full blow development project.
The Uleska Platform is a pre-built security integrator that covers all of the functionality discussed above. It comes with pre-built integrations to many of the commercial and open source security tools used by penetration testers and can be easily extended with custom scripts, in any language, to fit into any team. The Uleska Platform automates the execution or these multiple tools within the DevOps process, returning newly found issues to development teams immediately through their platforms like Slack, Jira, etc.
Issues found can be easily modified, are automatically prioritised based on business drivers. False positives and duplicates are recorded for efficiency. When new or different tooling is needed, there's no longer a project to get things connected - instead, it's just a matter of updating the Uleska Platform configuration and new security tooling can be running immediately.