Secure coding guides/standards for Cobol programming

sunhux used Ask the Experts™
Have got some links/guides from BTan previously for OWASP & Java.

I'll now need secure programming guides/standards for Cobol (the ones used in IBM mainframes/AS400)
esp those with good practices like:
a) proper input validation (eg: to mitigate against XSS & injections)
b) avoid hardcoding passwords &  IP addresses in the codes
c) enforcing session timeouts (session idle is forced to logout)
d) exceptions handling (so that under exceptions, the program doesn't bomb out, possibly to OS)
e) ...

For .Net & Java, we used Fortify to scan the codes;  is there equivalent scannners for Cobol?

========================  Past links I got from EE BTan =====================================

 The most common is use of OWASP recommended ESAPI in various lang for secure coding adopted by organisation practices
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
btanExec Consultant
Distinguished Expert 2018
I don't think there is secure coding guide for COBOL in specific - it has been asked by many in the past
I have two thoughts though, first:

1. The ones I viewed in the Java/C/C++ sub-pages were mostly "Best Practices" - and didn't have THAT much to do with Secure - as in Security
2. IBM COBOL - running under AIX, z/OS, IBM i, etc. represents back-end functionality - not directly address-able through hacking techniques like "SQL Injection" (which should be caught by Java, EGL or .NET front-ends

In summary, secure programming concepts and recommendations are language independent. Putting concepts into practice is very much language dependent, and when to employ which practices very much depends on the architecture, design, and interface points of the application itself. Those programmers familiar with Java and/or C and COBOL should be able to apply the examples from Java and/or C to their COBOL programs.

Even CERT did not look into this language -

As for the tool you may explore on below (no free scanner)
- Raincode Checker
- SonarQube
Other more from the list of scanner (Appscan, Fortify, Compuware Topaz)

there is some talk on simulation of COBOL control flow but it is more of tracer and suited for logic workflow of the data and control employed in the program, and may be more useful as error and troubleshooting kit.


Excellent, the sonarsource link has quite an extensive good practice constructs for cobol though nothing mentioned on cross site scripting, injection handlings.

So can we safely say Cobol is not susceptible to  cross site scripting n injection vulnerabilities due to the nature of the language?
btanExec Consultant
Distinguished Expert 2018

Partially as SQL injection is still applicable those the XSS is mostly targeting the Web front dealings. Most of the time, Cobol does  only alot of backend processing with SQL  statements. So input validation is still important for Cobol against injection of malicious statement.
Angular Fundamentals

Learn the fundamentals of Angular 2, a JavaScript framework for developing dynamic single page applications.

SQL injection is a "SQL" vulnerability, not "COBOL" as such. Of course, embedded SQL within COBOL is effectively equivalent to SQL embedded in C or Java or javascript or C# or perhaps any other language. That is, coding against the vulnerability employs practically the same methods mostly independent of language. That is, COBOL is not susceptible to SQL injection, but SQL embedded in COBOL is. Whether any such SQL is exposed for external manipulation is questionable.

We might say similar things about XSS depending on how COBOL is involved. It can hardly be considered as any part of "scripting" in the environments that you mentioned, though technical possibilities do exist. It's hard to imagine why anyone would want to go to the effort required given the alternatives. Any examples that I can realistically think of would involve (probably) deliberate coding by a developer at the site. Protection against that should involve fairly standard controls over who installs what.
Exec Consultant
Distinguished Expert 2018
Thks tliotta.

Programming COBOL applications that issue SQL statements should be subjected to injection inputs checks too.

In fact there is also instances of COBOL Web Services with the Microsoft SOAP Toolkit. In this sense even Web attacks are possible.

The terminology are of concern but the intent through those vectors or carriers are still applicable collectivity. Proper Verification and Validation will be the revelations of how assure the codes are having a reduced attack surface. It really depends ob the nature of the dynamic and static codes in the Cobol driven environment.
btanExec Consultant
Distinguished Expert 2018

thanks for sharing.
Indeed exception handling is part  of coding practices too, there should not be unknown return state in function calls or undetermined values of return values of the parameter pass in to the function etc..Developer hygiene as basic - this is not even secure coding (yet) but guidelines for completeness to address all scenarios during interaction and exchanges of the program flow. Control flow checks are critical and form the major focus for capturing deviated unlegit behaviours in the program during its execution.


One last query (hopefully):
does Cobol call Java or .Net  (just like Cobol call SQL) ?
btanExec Consultant
Distinguished Expert 2018
Treat Cobol as a object oriented language. It will normally call Java or. NET objects or vice versa - Not only one way call from Cobol only.
Java is supported through a Java domain in Object COBOL. The Java domain enables you to declare Java classes inside a COBOL program. You can then send messages to the Java classes. You can also send messages from Java classes to COBOL
This article explores calling a standard procedural based COBOL program from C#. It also provides an example of calling an object oriented COBOL class from C#
Your original question referred to "IBM mainframes/AS400" and your latest comment asks about "Java or .Net". Since .Net and Java are very different with very different interfaces and can run on very different platforms (Java runs on "IBM mainframes/AS400" but .Net doesn't), it's not clear what your latest question is asking.

For example, for "AS400" COBOL calling Java, you might review Calling Java Methods from a COBOL Program. But that's all about "JNI" rather than "RMI", so it takes some work to bridge the gap. And it doesn't do much for COBOL calling .Net; for that you might need to look into cross-platform technologies (I'm far from experienced in calling .Net from that direction).

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial