By Philippe Torbey, Lead Technical Program Manager
Achieving FedRAMP High Authorization While Maintaining Agility and Security
Too often, the development of compliance processes is viewed (and executed) as an agility killer, but if done well, it can be an opportunity to reinforce good agile practice and become a competitive advantage. Facing the challenge of hardening our platform and processes for FedRAMP High certification, at Hyperscience, we didn’t want to just check the boxes, I wanted to find a better solution.
Meeting the stringent security and compliance requirements of the FedRAMP High certification is no simple task. It involves an extensive audit of every part of our business and technology operations to ensure that every step is both auditable and secure.
Changing our development processes was a balancing act. In essence, what I was tasked to do was the following: how can we make our processes robust enough to meet federal government criteria and expectations for security while maintaining our agility so that we can continue delivering high impact features to our customers quickly? If done right, this can turn processes – a word that, I’m sure, many of you dread- into a competitive advantage.
Today, I’d like to talk about the core principles we leveraged to be both secure and agile in how Hyperscience develops software.
Overview
The agility of our Software Development Lifecycle (SDLC) comes from three guiding principles we based the process on:
- Security shift-left: involve Security earlier in the SDLC by including them in the ideation of new features
- Early alignment for greater autonomy: all teams understand the building blocks of secure development and their role
- It’s all about the people: a cross-functional Change Review Board verifies checkpoints to ensure their effectiveness
Hyperscience follows an agile development methodology with four phases that repeat in an iterative cycle shown below. Each phase is marked by a set of deliverables and checks to make sure things are ready to move to the next phase. As a summary, the four phases are as follows:
- Discovery: Defining, designing and validating solutions
- Implement: Turning requirements and designs into working code that meets Definition of Done
- Deliver: Final testing and hardening of the platform, and distribution of the new version
- Learn: Retro actions + Bug fixing & Incremental improvements
Security shift-left
Our Product Security team does not simply run scans and review code changes. Instead, we have embraced a shift-left mentality to security. This means that we include Security as early as possible in the process (to the left of the diagram!). Our Security team ideates with the Engineering teams during discovery, providing key architectural insights and influencing the designs of our new features from the get-go.
During development, Security is informed of changes to the design, provides feedback, and reviews the new designs. Finally, as the feature reaches the end of development, the team does a final review of the implementation before the feature can meet the Definition of Done.
This method offers a few advantages. First, this saves excessive review times at the end of development cycles and avoids expensive back and forth between teams. Second, it helps keep teams security-conscious. This creates a virtuous cycle where we all learn over time and get more secure as we go.
Autonomy through Training
We have designed a process where teams can perform certain checks, and trained them on which checks need to be performed when, by whom, and what the criteria needs to be. As such, development teams are empowered to perform certain checks, and to raise their hand when they require review and signoff by other teams such as QA and Security. Some changes will always require checks, and others are left at the teams’ discretion. Some of these checks include: documentation, security reviews, and product user acceptance training (UAT).
It’s not a matter of checking boxes. Each team is accountable and responsible for ensuring their projects fill in the appropriate checks, and effective training here is critical to enable teams to be autonomous enough to make the right decisions. Not just on what to do, but also on why it is important.
It’s All About the People
A team that regularly reviews changes consisting of people who actually do the work will be far more effective than far-removed process owners.
To ensure the checks we put in place are effectively being used, and that we remain compliant, we introduced a Change Review Board made up of a cross-functional subset of different departments with the following responsibilities:
- Propose, approve and implement changes to our software development processes
- Regularly review a sample of change tickets to make sure they are compliant and that checks are being used effectively
- Reviews sample change tickets to ensure the team’s self-assessment is correct.
The Change Review Board regularly meets to proactively look for opportunities to fix gaps and solve issues through automation and coaching teams.
Wrapping up
By balancing rigorous security standards with a commitment to agility, we’ve proven that achieving FedRAMP High authorization doesn’t have to come at the expense of innovation, velocity or flexibility—it’s possible to secure your platform while keeping it nimble and responsive to change.
