Development teams need to deliver quality software on time and within budget. Successful teams establish goals at the beginning of each project, and they communicate continuously to navigate dependencies and innovate. Developers support each other to solve these problems during fast sprints, and application security (AppSec) engineers ensure that dev teams deliver secure code without thwarting developers’ objectives by partnering closely with them. Otherwise, devs may see AppSec engineers as critics—or worse, as obstacles—if the technology and processes to discover and remediate vulnerabilities interfere with devs’ sprint cycles, delay delivery, and make them miss KPIs.
So, how can an AppSec team turn this dynamic around to partner with developers in AWS and partner with AWS to keep pipeline and cloud security standards high?
Deliver Fast Real-Time Feedback on Application Vulnerabilities
AppSec engineers have a formidable duty. It is common for one AppSec engineer to support hundreds of developers who own a broad scope of work with ever-evolving technology. Developers today, organized in small cross-functional teams, own more of the end-to-end dev process, including deployment, tooling, and nonfunctional requirements like security. Since code now drives everything, Developers are responsible for the full stack: source code and the code required to deploy and test the application. For example, Infrastructure as Code vulnerabilities are misconfigurations in the code that deploys the application a certain way and does not tie into the original source code the developer wrote. Nonetheless, it is within their realm of responsibility to fix those misconfigurations.
When teams deploy new software daily, they need real-time, actionable feedback from their application security testing (AST) tools. A minor code change could have unforeseen impacts on the rest of the codebase, so it’s critical to have automated security testing built into your deployment pipelines for the whole stack (infrastructure, application, and dependencies).
Furthermore, the widely varying dev processes from team to team complicates the process of quickly securing code. AppSec tools must be easily fine-tuned and customizable to ensure practitioners can automatically scan for relevant risk, tuning queries and results to fit the context. For example, is the app deployed on-premises or in AWS? A given vulnerability might present a low risk in one environment but unacceptably high risk in another.
One example of unforeseen impacts is when, Checkmarx scans for AWS discover active secrets, critical yet common when a customer moves a large old application into AWS. Code didn’t change, but the environment did, thereby rendering it vulnerable. Another common finding is an incorrectly configured S3 bucket with sensitive data allows “world read,” which means it’s publicly accessible. Therefore, AppSec engineers need the ability to adjust AST solutions depending on the app environment, company risk appetite, and industry compliance mandates.
Checkmarx can take the results of a scan and provide a “filtered view” back to the developer. If we find 100 vulnerabilities from a scan in AWS, for example, but the organization decides only one or two of those need to be fixed immediately, Checkmarx can filter that feedback to the developer. To do so, organizations must start by establishing a policy around which vulnerabilities have the most significant impact on an application based on inputs threat modeling or the criticality of an app.
One of the most common environmental factors used to configure AST solutions is configuration based on an application’s threat model. Applications deployed on AWS in private subnets and with WAF integration in AWS API Gateway, for example, may prompt you to use more relaxed AST profiles than you would for applications deployed in public subnets and without WAF integration.
Likewise, whatever scanning processes AppSec engineers are using to find vulnerabilities need to weave into developer processes smoothly. Checkmarx integrations orchestrate a series of automated events, such as scanning, presenting results, ticketing, identifying Best Fix Location, and suggesting remediations. AppSec testing solutions like this connect and streamline the work between DevSecOps tools in AWS and other cloud-native environments, delivering only prioritized and actionable data to developers.
Have a “No Ivory Tower” Mentality
AppSec engineers also need to help train developers to avoid and resolve vulnerabilities—considering time and budget constraints, of course. Rather than maintaining an ivory tower atmosphere and simply prescribing security requirements, it’s essential to keep in mind that preserving code security is everybody’s goal. Anything that doesn’t contribute to that ethos isn’t relevant.
Cultivating a kind of strategic minimalism will make processes more efficient. A notion persists that AppSec engineers need to focus solely on checking code every day, but this is counterproductive. With small security teams supporting large, agile development projects, it’s essential that AST solutions only run scans at times or places in the process when developers can act on the results.
Search for Relevant Software Vulnerabilities
Look at the percentage of scans that occur for zero code changes. If 80% of scans don’t result in any changes, even when you’ve tuned your queries and customized your results to fit your security needs, there is no point in scanning so often. It risks overwhelming developers with irrelevant results, and in the meantime, the team isn’t finding the vulnerabilities that have real business impact. For example, some vulnerabilities aren’t exploitable because of how code interacts, so addressing these will slow your devs down without benefiting the business. Searching for relevant vulnerabilities and running audit scans away from the development project lets you deliver the results developers need to act on and address to move on.
Things Small AppSec Teams Need to Avoid
Focusing on business impact also means avoiding some common missteps.
1. Building Your Own Pipeline
Automation is faster than any manual process, but don’t reinvent the wheel. Use standard tools. Many are very flexible, and you won’t need to spend a lot of time building an orchestration tool that is more cost-effective to acquire. AWS CodeBuild, CodeDeploy, and CodePipeline are excellent services that Checkmarx can integrate to get your pipelines up and running quickly and efficiently.
2. Building Your Own Security Scanning Infrastructure
There is no point in scanning everything if developers can’t act on the results. The Checkmarx platform scans uncompiled code and doesn’t require a complete build. Our unique “Best Fix Location” algorithm accelerates time to remediation by enabling developers to fix multiple vulnerabilities at a single point in the code. Developers, however overworked, are keen to take on security responsibilities and make necessary fixes, and the continuous feedback loop helps provides visibility into their progress, keeping them motivated.
3. Cobbling Together Multiple Tools
In a complex environment, the effectiveness of many individual tools depends on how well they work with the rest. For example, in the Checkmarx platform, vulnerabilities identified by static analysis in CxSAST link to relevant lessons in Codebashing, providing quick and targeted remediation guidance. These bite-sized, gamified secure coding lessons teach the developers about the vulnerability, how to fix it, and how to avoid making the same mistake again. Perhaps better yet, our CxSCA solution works with CxSAST to delineate the exploitable path of an open source or third-party software vulnerability.
4. Trying to Train Developers Yourself
Convince developers to take a break from their day job—where their performance is measured—to undertake training is tough. Getting real buy-in is even more challenging. If you’re going to deliver training, it needs to be relevant. It needs to enrich your developers, not just prescribe what they have to do. Ideally, it comes in short, actionable snippets. Frankly, most devs are not secure coding experts, so you need to partner with them and create a comfortable space to bridge the gap. Codebashing is measurable, so your executive team can see exactly how it’s helping your developers deliver ROI for your organization.
Small Security Teams Need Visibility, Automation, Actionable Data
Ultimately, AppSec engineers—particularly those with small teams—need a divide-and-conquer strategy. They need to find the most effective way to keep the team moving, creating a positive attitude toward security. Providing teams with automation, visibility, and continuous actionable feedback will make developers a more vital part of the equation. AppSec teams can help developers improve code quality, and the flexibility in the Checkmarx platform will enable them to do this incrementally.
Does your current AppSec tooling hit all four targets above?
If you’re not sure or if your answer is “no,” come check out our Checkmarx integration partnership with AWS here. >>
The post Fast, Secure Development in AWS with a Small Security Team appeared first on Checkmarx.com.