Originally published on GovDevSecOpsHub, this discussion from Checkmarx leaders discusses how the Department of Defense is improving its application security posture by adopting rigorous application security testing. Approved solutions are now stored in the Department of Defense’s “Iron Bank” repository. Continue reading to hear their thoughts and how the current security threat landscape is making application security testing essential in the military.
In early December, software security solution provider, Checkmarx, announced that its application security testing (AST) solution had been accepted into the U.S. Department of Defense’s (DoD) “Iron Bank” repository, and was available through the U.S. Air Force Platform One application portal.
AST solutions are becoming incredibly vital as application development teams move towards a DevSecOps approach and methodology for deployment because of their ability to help developers code more securely – effectively enabling vulnerabilities to be found earlier in the development process, and remedied immediately.
To learn more about Platform One, the Iron Bank, and how the military will benefit from the inclusion of the Checkmarx AST solution in the repository, we recently sat down for a conversation with Peter Archibald, the company’s Regional Sales Manager for DoD and FSI sales, and his associate, Jeff Ingram, a DoD Regional Sales Manager at Checkmarx.
In part one of our two-part discussion with Peter and Jeff, we explored the security threat landscape facing military organizations that is making AST essential, the need for software factories and pipelines for accelerating application development, and what the inclusion of Checkmarx in the Iron Bank means for military application developers.
Here is what they had to say:
GovDevSecOpsHub (GDSOH): Can you tell our readers who may not be familiar a little bit about the Air Force’s Platform One portal? What is it? Who uses it? What does it make available to users?
Peter Archibald: Platform One is a pipeline methodology and demonstration program that will show – first the Air Force, and then other agencies in the DoD – how to put together an effective DevSecOps program. This will really be a “plug and play” platform where different users can use whatever component works best in their environment, and whatever provides the best results in terms of quality and security scanning.
Jeff Ingram: Platform One is looking to take on managing and developing the pipeline so that the Software Factory can focus on developing software faster.
Our adversaries are developing and deploying capabilities faster than ever before – presenting a significant challenge for the DoD and all other organizations to manage. The Authority to Operate (ATO) process has really prevented the military from distributing capabilities to the warfighter quickly. Baking in a continuous ATO will help push capabilities out faster that are secure and ready to be deployed.
Developers that have been in the industry for many years are great at building software, but they often lack expertise and training when it comes to automating and securing pipelines. And that’s where Platform One has stepped in. It creates a repeatable process to allow pipeline sharing, in some cases, or pipeline customization for other programs.
GDSOH: On a similar note, can you tell our readers about the U.S. Department of Defense’s “Iron Bank” repository? What is its relationship with Platform One, if any?
Peter Archibald: The other aspect of Platform One is the repository called Iron Bank. This is where containerized pipeline components – both open source and commercial – can be submitted.
The containers are scanned for security purposes, and, once approved, can be used by anybody within the DoD. If they create their Platform One pipeline from those containers, that pipeline has an automatic ATO.
The longer vision on this is that the ATO for the pipeline can be extended to the actual application under development, itself. However, they are still working through the two first technology steps – which are standing up and populating the Iron Bank repository with pre-certified containers from industry and the open-source community and defining the pipeline that can be used in a “plug and play” manner with these authorized containers across the different types of DoD development environments.
Both Platform One and Iron Bank fall under a program named Level Up, which is managed by an office called AFWERX. The naming conventions get a little bit confused, but Platform One is the pipeline, and the Iron Bank is a repository of containers that support the pipeline
GDSOH: Checkmarx recently announced that its AST solution has been accepted into the Iron Bank and is being offered through Platform One. Why is this important to application developers working on behalf of our military? What tools or capabilities does this give them?
Jeff Ingram: This is important to application developers working on behalf of the military – whether they’re military service members or in the contractor community – because it brings industry-leading static application security testing (AST) – our source code analysis capabilities – to every pipeline within the DoD that is leveraging Iron Bank.
In the past, every DoD customer that we work with has to go through the process of getting Checkmarx’s AST approved for use in their environment. Inclusion in the Iron Bank provides DoD reciprocity to any pipeline or any development team. This greatly streamlines the process allowing them to bring security into their pipeline and secure their code as soon as they start developing.
GDSOH: Why is AST so essential in the DoD? What does the threat landscape facing the DoD look like? How large of a threat or attack surface are military applications?
Peter Archibald: There are two answers to this question. One of them involves compliance and the other involves addressing the real threat of malicious actors.
The compliance piece of this originated in the NDAA starting in 2013. There was a great deal of specificity concerning application security and software security. It wasn’t the DoD community that pushed for that, but rather the Congressional Defense Committee staffers that said, “we don’t think that the applications are secure.
Since then, the AST requirement has been tamped down – or even removed in some cases – in subsequent NDAAs, but it became policy within the DoD. So, there is a policy requirement for application security testing. It has become mandatory.
Then there’s the real threat. There are very sophisticated attempts to infiltrate our systems, access our data, and interdict our missions through information technology. For certain types of targeted attacks, our adversaries may even be spending more money and time attempting to access and infiltrate a system than today’s organizations spend on building and operating it.
The next big conflict is going to be all about cyber and signals. That means the whole information technology stack is at risk.
One of the things that’s really kind of incredible is that, whenever our enemies access corporate networks, they go looking for software repositories. Almost immediately, they’re looking to access the blueprints of software applications. That’s the quickest route to identifying weaknesses, and that’s why – when they get on the network and they get access – they start downloading software repositories first.
Jeff Ingram: How large is the threat or attack surface? It’s massive.
Software runs everything. And it’s only growing. Software is becoming more and more important and running all systems, from building and infrastructure systems to weapons systems.
In part two of our two-part conversation with Peter and Jeff, we discuss the evolution and adoption of DevSecOps in the military, the need to move security testing to earlier in the development process, and the benefits that AST can deliver to users.
This article was originally published on GovDevSecOps Hub on January 29, 2021