Development teams don't have to experience security as "yet another tool" or as "yet another process" that slows things down. This approach could finally help security make a significant impact on reducing risk for cloud-native software development. If there are issues, the security team should track them back to dev owners and establish policies and templates so that they don't repeat the same mistakes. Developers should leverage APIs to integrate security solutions into the tools they already use while giving security teams visibility into what has been tested and fixed. This shift weaves security into the existing CI/CD processes. By testing Terraform and CloudFormation for security before execution, just as they would test their application code for quality and reliability, developers can make any fixes before committing code to production - where it could affect customers and result in data loss. To quote Bilbo Baggins in The Lord of the Rings, "I feel thin, sort of stretched, like butter scraped over too much bread."Ī modern shift-left approach shifts security responsibilities to those creating software, the developers, and it shifts it to the beginning of the process when the developers are provisioning infrastructure. This model simply does not scale when companies are confronting modern decentralized development. I'd estimate that the current industry ratio sits around 1.5 security experts per 100 software engineers. Large development teams (DevOps, SREs, developers) that are armed with CI/CD and IaC are unstoppable. On top of this, in most organizations I've worked with, security is vastly outgunned in headcount. All of these tasks are costly and time-intensive. These experts may be available for a plethora of tasks: "threat modeling" new architectures, defining security features, consulting on risk priority, training up security champions and such. Inserting security into development has also traditionally meant hiring and deploying software security experts into development teams. It requires pauses between deploys to complete security scans, and then it requires time for remediation activity to catch up. It's a frustrating process that was designed to work in slow multistep release cycles with defined approval gates. You can run a static analysis of application code and dynamic analysis of live applications, generate reports, pummel your ticketing systems for remediation work, and curse at false positives. You can try to catch vulnerabilities and misconfigurations before they are exploited to reduce the risk of breaches in production. Last generation's shift-left security has been trying to shift left for years. The problem is that by this point, these problems can be difficult and costly to fix. These problems manifest at runtime, where security teams have good visibility with solutions that detect configuration problems. Rapid deployment of IaC by multiple developers of varying skill and experience levels means there's a high chance for mistakes. The problem is that there is often little to no room for traditional security intervention in this development process. Software provisioned with IaC can go from developer laptops to clouds to customers in seconds. The power and scale of modern software development cycles adds a new risk dimension to security. If they want to make changes or tear down the infrastructure, they code it, test it and then deploy the changes. This has shifted DevOps left and allowed developers to provision their own infrastructure using software development practices such as writing, testing and executing code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |