Segregation of Duties for HPE Fortify Software Security Center

Are you one of the many users of HPE Fortify with only one instance of Software Security Center (SSC)? Why? In my experience, it’s been much better to maintain a segregation of duties between the scan-upload-fix-rescan SSC instance and the reporting or dash-boarding role.

Bridging the gap between On-premises and Cloud-based Application Security Testing

In today’s connected business world, applications know no boundaries, as enterprises conduct business ubiquitously via ‘the Cloud’.

At the core of enabling this exponentially growing move are Cloud resource providers, like Amazon’s AWS, HPE’s Helion OpenStack Platform, or Microsoft’s Azure. Working in tandem (no pun intended) with the DevOps movement/systems/technologies and Agile software development teams, I am seeing greater geo-diversified (decentralized) software development happening at a pace never before possible.

In an effort to be first to market or to update/streamline antiquated back office systems, to maintain their competitive edge, companies are blurring the line between on-premises and cloud applications. Companies are writing more software, at a faster pace, than ever before – a trend whose natural evolution is to never reverse or slowdown. With companies writing software themselves or partnering with an outsourcing firm to provide either developer resources directly or delivered software, the challenge of gaining and maintaining insight into the security posture of the enterprise application landscape is also growing.

As such, I’d like to share with you a shift in paradigm for using HPE Fortify SCA/SSC and Fortify-on-Demand to fit your DevOps and Agile needs, no matter how fast or large.

With Development teams split up across the world, into independent entities, their leaders maintain independence in all aspects of the SDLC, from design, to development, to testing, and release. This also includes security testing integration and automation. For HPE Fortify SCA customers, having a dedicated SSC instance per development team is no exception. By enabling a development team with their own dedicated, mutable instance of SSC that they can use for continuous scanning, uploading, triaging/auditing, and rescanning, they can continue their independence and shift security activity further to the left, without having to rely on external resources to achieve their security goals and without impacting the reporting of current state security. No longer do they have to share a single instance of SSC across the entire organization for the scanning, uploading, triaging, and reporting, yet maintaining consistent reporting for measurement and tracking purposes, is still critically important. And it does not matter if the teams are using HPE Fortify-on-Demand or on-premises SCA, with CentralView it all becomes possible. DevOps is the new ‘faster, bigger, better’, so why do it without security?