Software Security For FOIA Management

Does Your FOIA Management Software Solution Follow These Best Practices for Security?

Below is a transcript of GovQA’s Audio Series on Software Security, which was recorded on 1/15/20. This episode outlines five key steps to follow for software security best practices with FOIA management SaaS solutions.

If you like this episode, watch for others here on

  • The State of the State-Level Public Records Landscape — An interview with Jen Snyder, GovQA Chief Sales Officer
  • Getting It Done in the World of Public Records — GovQA talks to Will Repole, Chief Operating Officer and Co-Founder of GovQA.

Interested in subscribing to the GovQA audio series episode alerts?  Sign up below.

Learn More About Security

Listen Now

Episode 01152

GovQA’s audio series will cover topics that affect and impact both you and your peers in public records managing FOIA requests. From security to legislation to litigation to solutions — this is another way we leverage our experience and expertise to support you in your day to day. Subscribe to never miss a new episode.

Topic: Software Security for FOIA management with Anthony Franciskovich, GovQA’s Senior Director of Application Security.

Episode 11520 Transcript

Software Security for Government Workflow Solutions like FOIA Management

Recently, we sat down with GovQA Senior Director of Application Security, Anthony Franciskovich, to chat about software security. Listen in or read along to learn what Anthony had to say about how GovQA secures all our software solutions (including FOIA Management tools). The transcript below contains clarification and definitions not in the original audio.

Melanie: Hello, this is Melanie Pusateri, content marketing manager for GovQA, here with Anthony Franciskovich, Senior Director of Application Security for GovQA. Today we’re going to chat about software security as it applies to state and local government agencies charged with managing public records (FOIA) requests and other sensitive documents and information data types. Welcome, Anthony.

Anthony: Thanks Melanie. Good to be here. 

Melanie: Anthony, you are one of a over a dozen folks in our tech department, working hard to ensure we continuously deliver the best possible technical solutions for our customers every day. Would you mind telling folks a little bit about your role here at GovQA?

Anthony: Sure, I oversee three areas in the technical department: Compliance, Quality Assurance, and Application Security. Application security is where I get my hands dirty the most. It’s where I ensure our software is built securely — following industry standards and best practices.

GovQA Optimizes Software Security Throughout Entire SDLC

At GovQA, we take software security from cradle to grave. From the beginning of the SDLC (Software Development Life Cycle), when the requirements are specified with the design…part of my job is to review the design and determine if there any security concerns: is there anything I or somebody else needs to look at?

And then, along the course of software development…we have code reviews and security code reviews. A “code review” is basically one developer looking at another developer’s work to make sure it has followed best practices. Our developers will keep security in mind. And we have certain policies in our SDLC that say if the code meets this criteria, we need a security code review.

Typically that will be a third set of eyes on the code; and that’s where I come in. I look at the code that’s been put in place to see if it breaks any of our security policies – such as if they used certain libraries that we don’t use…if they used outdated encryption algorithms. I’m going to make sure it’s built secure.

That’s really step one: the security code reviews we have in place.

Open the infographic above to download it for personal use, or use the share buttons below to share to social media.

View Infographic

Software Security for FOIA Management Step 1: Security Code Reviews

GovQA’s SDLC has security built into it. Large sections of our SDLC include security – and not just best practices…but our definitions of security. We specify the things we need to check. For example, if you’re touching any of one of these items (in the FOIA management software sode): user accounts, staff accounts, security profiles, departments…a security code review will be triggered.

The next thing we do to ensure software security, is to run automated processes.

There are automated tools out there to look at your code to see if you’re following Microsoft best practices and other industry standards. And the tools we use do that…but also are heavily focused on application security.

So if I’m in there doing a code review…there could be things that I missed…because I’m just another set of eyeballs. And…we have a few hundred thousand lines of code. Possibly upwards of a million or two now. I haven’t counted in a while. So, for the things I might miss or that slip through the cracks, we have an automated process that looks at every line of code and tells us where there might be a security flaw.

Software Security Step 2: Static Code Analysis

For this second step, we use an automated tool, called a SCA (static code analysis). We run that before we make every release to mitigate those issues before we actually go and make the release. This step helps us from the inside of the code base…out.

The third step is from outside of the code base…in.


Software Security Step 3: Web Application Scanning

The third step is web application scanning. The tool we use does not have access to our internal code. It’s from the outside. So what it does is called spidering, or crawling our website. It looks through all of our pages and all the different combinations of click paths. And it looks for what’s called OWASP (which stands for: Open Web Application Security Project). It follows OWASP Top 10. And it looks for things like possible cross-side scripting; cross-side request forgery. It will look at the data within a page — security headers/response headers — to see if we are securing up our pages, our information, our application that’s going over the wire back to our browser. It checks to see if we’re securing it up properly.

Melanie: The OWASP Top 10 includes: Injection; Broken Authentication; Sensitive Data Exposure; XML External Entities; Broken Access Control; Security Misconfiguration; Cross-Site Scripting; Insecure Deserialization; Using Components with Known Vulnerabilities; and Insufficient Logging and Monitoring.

Anthony: The web application scanning tool has the technology to look for certain patterns and properties that should be there. And if they’re not there, it will warn us and tell us which pages and which scenarios need adjustment.

We run that on a monthly basis. And we look to mitigate any high vulnerabilities immediately, mediums and lows within a certain amount of time.

Then, after that we use another tool, that looks at open source libraries.

Software Security Step 4: Open Source Code Scanning

GovQA prides itself on the fact that all of our core code was written by us in-house. And this will always be the case.  However, like most mature, modern, web applications, there is some javascript on the front end. 

Melanie: The “front end” of software development are tasks that convert data into a graphical interface (through HTML, CSS and JavaScript), so that users can view and interact with that data. This includes design/layout, text, buttons, images, and navigation links used in our FOIA management and other solutions on the GovQA Exchange Platform. 

Anthony: We do use javascript libraries which are open source for the front end — for the browser. And we check for bugs, security holes, security vulnerabilities in this code. These libraries change, every so often, weekly… quarterly…yearly…or never. We need to know what the vulnerabilities are for all the libraries that we use, and what the fixes are for those vulnerabilities. So we use a 3rd party tool to scan our software and determine what we’re using; where we use it; if there are vulnerabilities in that source; and what the level of severity is for those vulnerabilities. The tool also provides recommendations for how to fix vulnerabilities. For example, we may need to upgrade to the latest version, a certain version, or maybe replace one open source library with another that is more secure.

So that’s our 4th protection. 

Software Security Step 5: Third Party Pen Testing

Then, to round it all up and complete the full circle, we will do 3rd Party Penetration Tests. We believe we do a great job in making sure our software is secure…that no one can get through and look at our customers’ data or look at our intellectual property or take down our system.

All the steps I’ve outlined so far: Security code reviews, web application scanning, the static code analysis and the 3rd party open source library scanning — these things help us do a great job when it comes to securing our software. But we don’t just go with our word…we get a third party in here to actually try to get into our system and find any additional vulnerabilities. In these 3rd Party Pen Tests they try to punch through and exploit potential vulnerabilities. 

Melanie: Well I’m glad we’ve got you on staff here, Anthony. 

Anthony: It’s a great job and I do love doing it. GovQA has a great product. And a really good environment.

Melanie: Thanks for giving us some insight on these security topics. I think it will help our FOIA management customers (and all GovQA customers) to better understand some of the lengths GovQA goes to to secure our software.  I’d love to stop by again in the near future for an update.

Anthony: It’s my pleasure. I love talking security. Come by any time. I’d be happy to talk with you.

How to Ensure Software Security For 2 Million Lines of Code

  • Security Code Reviews
  • Static Code Analysis (SCA)
  • Web Application Scanning
  • Open Source Scanning
  • 3rd Party Penetration (Pen) Tests

Subscribe to the GovQA Audio Series

GovQA’s audio series plans to cover topics of interest to you and your peers in public records. From security to legislation to litigation to solutions — this is another way GovQA supports you day-to-day. Subscribe to be the first to know when new audio episodes are posted.

The Peers in Public Records Newsletter (formerly FOIA News) is a bi-monthly e-newsletter brought to you by GovQA. It is a collection of the latest trends in public record requests and government transparency initiatives, shared stories, live roundtables, informative case studies, and actionable knowledge that will help you calm the chaos and keep your organization compliant. Send your comments to

Subscribe to the Peers in Public Records Newsletter