Hand in hand: Application development and application security
As expectations of developers change, so too do those of security teams. It’s more of a collective effort than ever as business dependence on applications continues to grow. Security must shift further left into the software development lifecycle (SDLC), which means developers take on new responsibilities previously managed by ITOps, and new monitoring and assurance tasks are created for security teams to ensure deployment is smooth.
Complexity, flexibility, and success
Organizations are moving further into cloud operations, and a larger thought shift might be in store for some more than others. The traditional infrastructure model of standing up a server and running code was much simpler; teams knew what their vulnerabilities were and what their exposure looked like.
With cloud-native services like Kubernetes, exposure can increase exponentially as new instances of an application are automatically spun up to deal with scale. In this scenario, one instance of a vulnerability could easily go unchecked and turn into a thousand. However, today’s apps provide much more flexibility to reach success and, at the end of the day, developers need to be able to scale at the speed of imagination so they can continue to innovate and drive value for the business. How, then, are organizations to maintain continuous compliance—and communication—between development and security when attempting to control large fleets of complex cloud assets and environments?
Security concerns create solutions
Everyone relies on someone—or several someones—to succeed. But of course, this exposes operations to ever-increasing vulnerabilities inherent in things like:
- Third-party security services and applications
- Build-and-deployment pipelines
- Cloud-provided infrastructure
- First-party applications
Organizations will have different models of priority depending on the maturity and efficiency level of their cloud operations. For many, it might be prudent to start with build-and-deployment pipelines to create clarity and control over the majority of the above concerns. In this way, teams can have full audit of first- and third-party applications, and they can begin to gain more visibility over security operations. Full control over those operations may not come immediately, but gaining clarity is a big step in the right direction.
Control begins with culture
Containerizing services and creating specific product lines can empower developers to own and service their end-to-end process. For many developers, though, this can be a big transformation from depending on other teams to build infrastructure and then write code on top of it. This change won’t be easy, as it requires a lot of tough questions and observations in the way developers and security teams work together.
Tools like InsightAppSec and InsightVM from Rapid7 can facilitate this change by providing an immediate and significant amount of the cloud-security visibility that precedes greater control. Taken together, tools like these can help teams as they address the “growing together pains” and learn to shift security operations left; not only to identify and remediate vulnerabilities going forward, but also retroactively discover those that may have existed unbeknownst to anyone.
Leaders looking to bring developers and security closer can use these kinds of tools to enact the seismic cultural shifts that will continue to further blur lines between teams as they take on more turnkey independence.
Independence, for many organizations, might be conditional. The security team still needs to monitor build pipelines for vulnerabilities, even with many of those responsibilities now built into the development process. This is a good thing; it means deployments can get closer to stakeholder wished-for speeds.
Organizations may find that taking stock of cloud-security risk at the beginning of the process further mitigates future headaches. Providing developers with security upgrade paths via something as simple as clicking a button fosters goodwill and maintains security as applications go online and deployments accelerate. This isn’t to say that developers wouldn’t have access to dive deeper into security issues if they wish—or that it’s not their responsibility to do so—it’s simply helping to create a DevSecOps culture.
Creating security standardization points, unique templates-by-team, and standardized container images can help to accomplish the trust-yet-verify goal. This also helps to strengthen relationships between organizations and cut down on security requests that ask people to take on additional tasks as the CI/CD pipeline is steaming ahead.
The future is now
That may be a bit of a cliche, but modern applications spun up in the cloud contain more automated processes than ever before; the speed of business and its bottom lines demand it. And all of these moving parts aren’t going to wait for teams to slowly organize themselves into a more efficient working culture.
But it doesn’t all have to be done at once. Companies and teams are incredibly different, and each one requires its own bespoke solution. Polling personnel on processes and vulnerabilities can reveal actionable insights. It will then take the aforementioned goodwill between teams to quickly act on those insights and put sustainable solutions in place.
Want to learn more about how teams are finding new ways to shift left to create scale with their business-critical apps? Rapid7 recently cosponsored a SANS webcast featuring experts from around the industry weighing in on the need for speed and problem-solving in modern cloud environments.