Release early and often,
respond quickly to customer feedback, iterate. Rinse, repeat.
The value of getting new features and products in front of customers faster has made
its mark on the business world. As a result, development teams are under pressure
to shorten release cycles and meet tighter deadlines all while maintaining high
quality and security standards. How do experienced teams do it?
Accelerating the development lifecycle without cutting corners is no easy feat but
it can be done. While there's no "silver bullet" solution, adopting a security-first
mindset and a few workflow best practices can help.
Watch the our webcast with HackerOne below to get all the details on how you can build in quality and
security checks throughout your development lifecycle from GitLab's Product Manager, Victor Wu,
and GitLab Security Lead, Brian Neel.
You can watch the recording, check out the slides, and read a few of the highlights
below.
Security as a first-class citizen
Ensuring every line of code is secure is a shared responsibility, meaning security
should be top of mind from the very beginning of the development process. Don't wait
until the very end to start the conversation around security and check for vulnerabilities.
"We want to take security and make it a first-class citizen. You want security controls
baked into each stage of your development process. When we develop software and we
develop in small chunks, we always say we want cross-functional collaboration.
We want people at the table earlier on." - Victor Wu, Product Manager, GitLab
Whether you have dedicated security experts, or perhaps a lead engineer who's wearing
multiple hats, talk about security from the get go so that security issues
can be identified earlier, and vulnerabilities can be avoided altogether.
Workflow best practices
In the webcast, Victor details how DevOps teams can bake quality and security controls
into their workflows so that these checks don't become cumbersome bottlenecks at the
very end of the process.
Here are a couple of his highlights:
Make smaller changes and commit often.
Perhaps the most critical adjustments to make to your workflow is how you actually write
and collaborate on code. When we talk about development speed, a big part of this is transitioning
away from developing huge portions of code over long periods of time to making smaller changes more often
and making that work visible sooner.
"We want to ship smaller pieces, often. Whether it's in an agile context, scrum,
or moving away from the more traditional waterfall requirements, we want to ship
in small pieces so we can react more quickly and minimize risk." - Victor
By adopting this practice, it's quicker to perform code reviews and
security checks because reviewers are only dealing with a couple of changes. Then,
if there is an issue, it becomes much easier to identify the cause because there
are fewer new variables to consider.
Involve experts and reviewers early in the development process.
Involving collaborators and reviewers earlier in the development process does two things.
First, it can speed up the development process by giving stakeholders an opportunity
to anticipate problems before developers begin to write code, and nip them in the bud.
It's common to involve your UX team, product managers, and software architects during the
planning phase and throughout the code review process, but often security is left out.
Get your security experts involved in the earlier phases of your development process
so it doesn't become a bottleneck right before you're trying to release.
"Let's get our UX folks early on, let's get our business managers involved early on.
Let's not wait until very late in the game before we bring our product managers,
senior engineers, our architect, and security experts." - Victor
Secondly, by keeping all stakeholders involved in the conversation throughout the
development process, you can ensure that by the time the code is ready to move
into production, most errors have been spotted and corrected.
Get code into staging or test environments earlier.
This goes back to the high-level concept that we want to work on small pieces of code and get
them integrated into the mainline branch right away to minimize the risk of something not working,
or not accounting for certain things.
"The point of pushing code into production-like environments is to get your feature into a place that looks
and functions more like the real world," says Victor. Getting your code into staging or test environments sooner
can also help to minimize security risks.
"You might have certain tools to scan dynamically and inject attacks into
your systems, whether that might be directly into your data or your code base.
In the same way that you have human testers doing manual testing, in addition to the automated testing,
you might have human users doing the security testing as well." - Victor
Again, if you're developing in small chunks, involving stakeholders earlier on into those environments,
that they can jump into those environments and start testing the feature.
Leverage your community to spot and prioritize security issues and bugs faster.
Even with all the right quality and security checks threaded throughout the development process,
problems can slip through. In the webcast, Security Lead, Brian Neel, details the
evolution of the security development process (starts at 28:20) and why GitLab's security
team uses a bug bounty program to round out our security practices.
"Right around the time you push a beta out to customers, you can open up a bug bounty program, and it provides
sort of an endless coverage from prior to version 1 all the way through version 2 and into the future for any new
vulnerabilities. You're constantly going to have professional hackers out there testing this code, testing it against new types of
vulnerabilities."
