Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
Details:
I would be interested in how you guys handle assessing your vulnerability testing within an agile environment?
Example:
You have weekly test series in which you test your project for vulnerabilities. Weaknesses are found that cause lasting damage to your product.
What value do you place on these errors or vulnerabilities in agile development?
What workflow have you defined?
Agile methods are about fast feedback loops. The best practices for integrating vulnerability testing into the process will be different depending on what your process looks like. If you are using Continuous Deployment, for example, you may want to run some level of vulnerability scanning far more regularly than an organization deploying less frequently, such as on the order of one or two deployments per week or month.
I think there are some general good practices, though.
One good practice would be to have a safe and secure environment to perform testing against vulnerabilities. You probably don't want to do this in testing, mainly if a vulnerability is found and exploited. You want an environment where you can exploit the vulnerability and find its limits without affecting end users. This also enables you to run concurrent scans without affecting performance or stability for the end-user.
Another good practice is to use automation. Have your vulnerability tools set up and pointed at your testing environment and scheduled to run regularly. This could be part of a build process, where deploying a new version to the security environment triggers a scan. It could be schedule-related, running once a day or once a week. Be sure to not only consider scanning because of software changes but also updates to the scanner itself with new rules and patterns.
A third practice is to build security into the entire life cycle, rather than relying on it at the end. Train developers and operations staff on relevant security topics and standards so they can consider them during requirements, planning, design, and development activities. Incorporate static analysis into the build process to fail builds that don't meet quality rules, including introducing vulnerabilities. This can also help to enforce code style, and code style can make it easier to people to read and avoid vulnerabilities or reason about existing vulnerabilities. Consider human-led penetration tests from security specialists and find ways to improve your process to bring in the ability to find anything sooner. The goal should be to prevent vulnerabilities from being introduced while detecting any vulnerabilities earlier in the process.
The final practice would be to expand vulnerability management to third-party components. This includes third-party libraries bundled with the software. If the system is operated as software-as-a-service, it would also include the operating systems and operating system-level libraries. Not only should you patch for known security vulnerabilities, but ensuring that you are using supported versions can ensure that you will receive security patches if any are released.
Regardless of your tools and activities, treat it like a bug report once you find a potential vulnerability. First, confirm that it is real. Some tools have false positives or may flag a vulnerability that has other mitigations in place or perhaps the "vulnerability" is the system's intended behavior. If the vulnerability is confirmed, treat it like any other defect. If you have a no-bugs or zero-bug policy, that probably means working on it immediately after detecting and confirming it. Otherwise, it could mean putting it on the backlog in a place that makes sense, based on factors like risk exposure, difficulty to exploit, cost to fix, and so on.
