How to Evaluate the Maturity and Security of Your Public Sector Software Project

Share on facebook
Share on twitter
Share on linkedin
Over the past decade, commercial software organizations have embraced new approaches to software development that have allowed them to accelerate growth and rapidly deliver incremental value to the business and its customers. The tools and techniques that these organizations use have evolved to provide better and more secure software in less time while improving the return on investment to the companies. The era of multi-year projects with missed deadlines and exponential budget requirements is gone. In the early days of the DevOps movement, disruptive startups assumed a great deal of risk to achieve their results, and this is not something that a public sector organization could risk. However, as DevOps has become mainstream and further evolved into DevSecOps, the tools and practices have matured, risks have been mitigated, and it’s becoming increasingly feasible for government agencies to adopt a new approach to software development. Watch the webinar “On the Road to DevSecOps: How to Embed Security Throughout Your DevOps Workflows.” >>  In this article, we’re going to discuss DevSecOps from the perspective of the public sector organization. Specifically, we’re going to talk about establishing the right protocols and practices, and how to evaluate the maturity of your development, operations, and security practices. A mature DevSecOps practice provides a solid foundation to request an Authorization to Operate (ATO) and most importantly, better meet the needs of those you serve.

DevSecOps and Shift-Left Principles

DevOps is the consolidation of development and operations into a single team. At its core, DevOps establishes ownership of the software solution. This ownership results in great attention to building software, deploying it, and supporting it in production. Ownership creates responsibility and, through it, better design and better software. DevSecOps builds on this approach by injecting the role of security into the DevOps process. In the past, security was something that was validated and checked after engineering completed the project. The principles of shift-left move security to the beginning of the process. It becomes part of the original design, and we validate the security throughout the development and deployment processes. The principles of shift-left establish an engineering mindset focused on security from the start. Security becomes a primary component of design, engineering, and testing, creating a secure application from start to finish.

Correct Application of Security Scans

There is no one-size-fits-all security scan that can guarantee the security of your application. Different types of security scans check for known and suspected vulnerabilities and, when used in conjunction with engineering best practices, can validate the strength of your application against potential attacks and exploits. Investing the time to define your organization’s approach to security scanning, and automating as much of this process as possible, will ensure that all additions and modifications to the application receive the appropriate scrutiny. Partnering with established third-party providers, such as Checkmarx, allows you to leverage experience and expertise to supplement the work of your engineering teams. You’ll want to establish processes that perform the following types of security scans on your applications.

Static Code Analysis

Static code analysis examines the source code for the application and identifies known vulnerabilities and sources of potential exposure due to weaknesses within the application’s logic. These scans are usually specific to the language used to build the application.

Dependency Scans

Much of the speed in developing modern applications comes from leveraging existing software libraries. Many of these libraries are open-source and are frequently updated to add functionality and increase security. Dependency scans review the dependent libraries in a project for known vulnerabilities and potential exploits. If you’re newer to the world of open source and third party code, or simply want a comprehensive view, check out our eBook, Software Composition Analysis: The Ultimate Guide to SCA. >>

Vulnerability Scans

Malicious actors use a plethora of different approaches to compromising an application and its data. Vulnerability scans simulate many of these techniques and determine whether attackers can use them as a potential attack vector against the application. The potential for data injection, port abuse, and cross-site scripting are some of the vulnerabilities these scans can identify within your application. As we mentioned above, performing these scans regularly and early in the development process will ensure a more secure end product. The earlier you can catch a problem, the more you reduce the time and effort required to correct it. 

Establishing a Security Mindset

Security scans can be an essential and invaluable tool to ensure the security of your application. However, they are the last line of defense before you expose your application to the world. Truly secure code begins with the concepts of secure code included in the application’s design.  Employee awareness is your first line of defense against cyber-attacks. Providing training to your engineers will go a long way toward establishing a culture that values security. Engineers that understand how malicious actors might attack and compromise their applications can better defend against those attacks and produce more robust and secure code as a result.

Key Performance Indicators for Security

Well-trained and security-minded engineers, coupled with established processes to scan and validate your production code forms the foundation of your security strategy. Establishing and monitoring key performance indicators with respect to security will help you maintain and continually improve and mature your security processes.

Scan Results and Trends

Monitoring the results of security scans, including their trends over time, provides valuable insights into how well your organization embraces the principles of secure code, and learning from their mistakes.

Time to Detect and Resolve

Mean-time-to-detect (MTTD) and mean-time-to-resolve (MTTR) have become industry-standard metrics to determine how well DevSecOps teams are instrumenting and monitoring their applications. We cannot guarantee that an application will be free of bugs and errors. But ensuring that we respond quickly and effectively is critical to ensuring the security of our systems.

Operational Metrics

Your operations team may have additional metrics they recommend to monitor the health and security of your applications. Traffic patterns, error counts, and other metrics all provide unique and helpful insights into how the application handles user traffic and indicates potential abuse before it becomes a severe problem. 

Partnership and Learning More

In the quest to establish an organization with a mature software security culture, you may find it helpful to partner with organizations like Checkmarx that have established themselves as experts in this field. The private sector has been using and enhancing DevSecOps principles for the better part of the past decade. Their insights and experience may prove invaluable as you strive to improve your software development practices and deliver better and more secure services to those you serve. 

Related Articles

  Mike Mackrory is a Global citizen who has settled down in the Pacific Northwest - for now. By day he works as an Engineer Manager for a DevOps team, and by night he writes and tinkers with other technology projects. When he's not tapping on the keys, he can be found trail-running, hiking and exploring both the urban and the rural landscape with his kids. Always happy to help out another developer, he has a definite preference for helping those who bring gifts of gourmet donuts, craft beer and/or Single-malt Scotch.

Latest Blog Posts

Follow Us

Latest from Our Blog

Skip to content