Application Security - “DevSecOps”
At Vektren, we understand that security is a top priority for any organization. That's why we offer a range of DevSecOp services to help you secure your software development lifecycle (SDLC). Our team of experts has the knowledge and experience to identify and mitigate potential security risks at every stage of the SDLC.
With our DevSecOp services, you can expect:
Continuous integration and delivery (CI/CD) pipelines that are secure by design
Secure coding practices and training for your development team
Regular security testing and vulnerability assessments
Threat modeling and risk assessment to identify and prioritize potential security issues
Compliance with industry-specific security standards and regulations
Don't let security concerns hold you back from delivering high-quality software. Contact us today to learn more about how our DevSecOp services can help you build and maintain secure software.
What languages and files a developer/author has modified in the last X days?
Identify the specific security training needs can be defined
Automating the identification of training plans
Identify committer is outside the development team, e.g., Business Analyst
Identify a more accurate view of whose writing code
Identify the number of “named contributing developers” used for security licensing (e.g. the # of developers you need to be licensed for is anyone who’s committed code in the last 60 days).
| Name/Email | Git Server | Org | Repo | type | # Commits |
| Peter | Github.com | Team1 | utils | .java | 37 |
| Peter | internal.abc | banking | core | .js | 5 |
| Jack | internal.abc | banking | core | pom.xml | 16 |
| Jack | bitbucket.org | Shiny | main | .js | 15 |
Sample Data:
Vektren developed our own code scanner to help DevSecOpps (AppSec) teams identify coding languages and track intellectual property. It also checks for secret scanning and version checking to identify outdated packages with vulnerabilities. With DevSecOpps, you can quickly implement fixes with rich data exports, improve security in the development process, scan for secrets like passwords and API keys, and check the version numbers of software libraries and frameworks in your codebase.
What package managers are used?
Given vulnerabilities like Log4J, knowing where all the package manager files also allow direct searches to be performed during an incident, E.g. Where is Log4J used in our code bases?
We can extend these tests to look for package files not updated in X days, which may indicate unmaintained libraries.
Bonus test: look for package files not updated in X days; this may indicate unmaintained libraries
Often this data is used as a requirement for security tool selection. For example, 90% of our development uses maven and npm; these are mandatory requirements, and a technology fit assessment would focus on these technologies for integration and accuracy of results.
Given vulnerabilities like Log4J, knowing where all the package manager files also allow direct searches to be performed during an incident, E.g. Where is Log4J used in our code bases (Keep in mind this may also be variants like Scala, Clojure, kotlin etc.)
Package Manager Filetype examples:
| Package/Docuemnt Type |
| package.json |
| pom.xml |
| requirements.txt |
| gemfile |
What languages and technologies are used?
This use case came from the head of security architecture, stating developers were not using Docker. Upon looking at the code, many projects were using Docker, at least in development initiatives, for
Types of files that may be interesting:
Circle ci config
Package manager files
CODE OWNERS
Buildkite
Dockerfile
Terraform
This may be useful if there are multiple git instances and a migration plan needs to be developed.
Another related organisational use case is that we have a policy or practice where open-source libraries must be scanned every X days for vulnerabilities and releases. Which means:
The security team can use the data to know when package files exist and proactively work with teams to get it on the backlog to implement
The security team can run security scans themselves and alert on high-risk vulnerabilities
Development managers can understand who’s using what package managers and get their development leads to build out implementation patterns.
|
Git server |
Git Org |
Tech/Lang type |
# of Repos |
|
Github.com |
Insurance |
Java |
47 |
|
Github.com |
Insurance |
Maven |
13 |
|
bitbucket.internal.xyz |
Customer |
bitbucket-pipelines.yml |
6 |
Ideally, the output could look like:
What sensitive files exist within the development environment?
Some file types probably shouldn’t be in a repo, and if they are monitored for changes and hopefully form part of a migration plan (e.g. moving secrets out of repos
Examples of file types to watch or detect:
Anything binary - probably shouldn’t be there (it could be a code smell)
.PEM files (is this a key of some sort?)
*.p12 (certificate chains and potentially private keys)
Id_rsa (checked in RSA keys, maybe SSH)
config/environments/production.rb
There are better tools than SQL queries on filenames to detect secrets, but a mechanism to add files to watch with a known security impact would be cool.