Home QA Testing Why ‘Shift Everywhere’ Is The New ‘Shift Left’ For Software Testing

Why ‘Shift Everywhere’ Is The New ‘Shift Left’ For Software Testing

by support@1lyqa.com
why shift everywhere for software testing

Principal Scientist at Synopsys Software Integrity Group, innovating ways to build secure, high-quality software faster.

At this point, we’re all likely comfortable with the 16-year-old idea of “shifting left” — applying application security techniques earlier in the software life cycle. When the idea of shifting left was popularized, the only real tool-based option was to run static analysis during the coding cycle, which shifted some testing to earlier, and then doing penetration testing the proverbial “day before” the application went live.

For the past few years, I’ve documented the much more important idea of “shift everywhere,” where the software security initiative — also known as application security program or product security program — performs the right application security testing (AST) as soon as there is enough of an artifact to test anywhere and everywhere in the software life cycle. Whether that artifact is requirements, code, configuration files, scripts, process output, APIs, containerized applications or other similar things, the artifact is immediately tested upon creation for important characteristics such as security, quality, compliance, adherence, reliability, resilience and so on. (Of course, you don’t necessarily do all testing all the time; an efficient testing process requires intelligence-based orchestration.)

Culture Change

Doing this on-time, on-demand AST requires technology and automation, of course, but it’s really all about culture change. By this, I mean stepwise, program-level improvement that puts the organization on a path for long-term software security success.

In the vast majority of organizations, this culture change around automation, “test everything,” guardrails, digital transformation and so on is coming bottom-up from engineering groups. Security groups are struggling to get engaged, keep up with the new pace and do good risk management. The bulk of this organizational culture change must come from a top-down, strategy-first approach that drags behind it all the appropriate quarter-on-quarter changes in people, process and technology. A shift everywhere strategy is critical to long-term software security success, and a strategy focused just on technology is doomed to failure.

Among other things, “shift everywhere” means AST everywhere, and that AST has to collectively function as a telemetry generator, a single framework that’s part of the engineering plumbing. The AST results must be curated (perhaps with some application security orchestration and correlation [ASOC] automation) and presented to engineering teams when, and only when, prioritization indicates the issues must be addressed now. Use that telemetry to also diagnose both procedural and adherence issues. For example, you could require a configuration management database (CMDB) asset identifier for anything that is going into production. This is a fast test; no CMDB identifier equals no deployment (and no surprise software blobs)! There’s a wide variety of possible fast tests that organizations are either not doing or still doing via spreadsheets, phone calls, emails and expensive group meetings instead of automation.

Trust But Verify

Culturally, we need to trust but verify in many places, and security questionnaires might be a place to start. For example, rather than sending out generic questionnaires, run tests and preconfigure them with facts, then ask brief questions about why certain facts are what they are (especially if the facts shouldn’t be what they are). Reserve extended question lists only for those things you can’t test. You can also use the questionnaires to collaboratively set acceptance criteria for all the various kinds of downstream testing needed.

Remember, any “should” requirement from the security team will likely not generate the desired change. Culturally, what you want to accomplish must be stated as a firm requirement — like a coding standard or a nonfunctional security requirement (NFSR) — or be part of the acceptance criteria (like a guardrail), or it’s likely just a distraction.

In many cases, security teams no longer push these security requirements to engineering teams as email and documents. To be a cultural fit, teams must push some requirements into engineering automation through their own software development and release process (e.g., to implement a security guardrail in a CI/CD toolchain). This requires a change in application security philosophy and tooling as well as people and skill sets — that is, a culture change.

We’re years away from taking human judgment out of the software engineering process. What we’re talking about now is how we capture and apply some of that judgment in automation today. When we codify it, we can argue about it and get it right. We can talk about reality versus personalities. When something is proven wrong, we can all get smarter and fix it. When we develop sufficient trust in it, we can let the automation do some things while we watch, and then, later, let the automation do some things while other automation watches.

Original Source

Related Articles