Page 31 - info_oct_2021_draft13

First way SAST
The first principle says we need to accelerate SAST tools scan the source code of the
the work from development to operation, and then application and identify security vulnerabilities
to the customer. This can be achieved by limiting that may be exploited by the hacker while in
work in progress and through automation. production. These tools pinpoint the code
location where security issues exist. This tool
Second way is used by the developer while the developer
DevSecOps feedback from operation to development. This is writing the application and so the advantage
The second way enables constant flow of
of this tool is that the developer may fix all the
security issues reported by the tool during the
can be achieved through continuous integration,
build and deployment process working together development phase of SDLC.
with a fast, automated suite of tests.
SCA
Third way SCA tools scan the source code and binaries With traditional software develop-
The third way is about creating a culture of to identify vulnerabilities in open source libraries ment strategies, it is not possible to de-
continual experimentation and learning. included in the application. These tools not only liver secure software at high velocity.
uncover the security issues but also highlights DevSecOps is the philosophy of incor-
While DevOps culture brought a lot of the licensing risks due to open source software porating security practices within the
innovation to the software development process, components. DevOps using automation and security
security was either not considered or not able to tools, and thus enabling secure software
delivery through the seamless and trans-
keep pace with the rate at which software was DAST parent integration of security into the CI/
being built and released. DevSecOp is an attempt DAST is an automated black box testing CD pipeline.
to inject security into the DevOps process and technology that attacks our web applications/
make sure that software delivery rate is not APIs just like hackers would do. DAST tools do
disturbed due to this injection. not require access to source code to perform
DevSecOp is short for Development, Security the scan on web applications/APIs. Since these
and Operation. This technology dictates that tools attack the application in real time just like a RATNABOLI GHORAI DINDA
security is not the job of one group, rather hacker and provide proof for each of the reported Dy. Director General, NIC
everyone including development, security, issues, it has a low number of false positives.
operation quality is responsible for security. If any
issue comes in production, all the teams should
work together to resolve the issue therefore all that identifies the security threats by attacking
the teams should learn security. Security should the running web applications/APIs/ web services
not be an afterthought, rather it should be built just like hackers. It does not require source
into the application. Security should be discussed code of the application and can scan the
and practiced during all the phases of Software applications developed in any language.
Development life cycle during requirement It also provides proof of the reported
analysis, architecture, design, development, issues of what parameter tampering/
testing and in operation. manipulations/fuzzing were done and
its effect on the target application.
Hence, to deliver software at high speed and
make it secure as well, security needs to be built
into the application development workflow and Conclusion
process. The earlier we introduce security into If we utilize these tools regularly as a
SDLC, the sooner we will be able to identify and fix part of our design and development work, we
vulnerabilities in the software, rather than waiting will be able to eradicate security issues early
till the end for security assessment reports or DevSecOp in the SDLC. Moreover, the developers acquire
run time issues in the operation. Organizations a lot of security knowledge in the process and
can introduce security into existing continuous will apply these learnings in the other projects
integration and continuous delivery (CI/CD) In NIC, the Application Security Group is
pipelines. Just like after a build failure, software providing the following tools to developers to they work up on. All these things will certainly
is not eligible for deployments in the production, enforce security in the CI/CD pipeline through make a cultural shift in the organization and will
a policy may be defined by the organization, if a automation: ultimately make the software much more secure,
security issue is caught in the CI/CD pipeline, the robust and resilient.
application should not reach production until the HCL Appscan Source for Development
vulnerabilities are taken care of. This tool provides a plugin to integrate in
To implement DevSecOp, organizations need Developer IDE like Eclipse, Microsoft Visual Studio
to integrate application security tools into CI/CD etc. This allows developers to scan the code, find
pipeline. vulnerabilities and fix it during the development
Some of the tools are: phase of SDLC. This tool also provides For further information, please contact:
• Static Application Security Testing (SAST) recommendations for the issues reported by it. Anil Kumar Jha
Sr. Technical Director
• Software Composition Analysis (SCA) HCL Appscan Enterprise Application Security Audits & Assessment Division
National Informatics Centre, A-Block, CGO Complex
• Dynamic Application Security Testing (DAST) This tool is a black box security testing tool Lodhi Road, New Delhi - 110003
Email: aniljha@nic.in, Phone: 011-24305140

October 2021 informatics.nic.in 31