Building Trust in the Security of Software
Shore Apps Security Source Apps Security
Java- EE Onshore 215 4.25 Inhouse 277 4.56
Offshore 460 5.24 Outsourced 412 4.19
% of variance |
1 % |
% of variance |
n. s. |
COBOL Onshore |
83 |
1.94 |
Inhouse |
110 |
2.41 |
Offshore |
201 |
1.43 |
Outsourced |
206 |
1.60 |
% of variance |
n. s. |
% of variance |
n. s. |
NET Onshore |
87 |
5.12 |
Inhouse |
93 |
4.61 |
Offshore 112 4.89 Outsourced 138 4.98
% of variance n. s. % of variance n. s. Table 4-2: Comparison of security weaknesses per KLOC for differences in shore and source by language.
5 CONCLUSION
Three approaches to establishing trust in the security of a software system have been reviewed; the quality of the development process, the quality of the developers, and the quality of the software product. Information and data on security weaknesses in the software can be used in all three forms of evaluation. In particular, the security measure in ISO / IEC 5055:2021 based on an OMG standard provides a list of severe security weaknesses that constitute significant risk to the security of a software system.
These weaknesses should be incorporated into risk and assurance processes across development and deployment processes. Software developers should be able to recognize, avoid, and repair these weaknesses. Finally, the presence of these weaknesses in the code should be assessed throughout development, deployment, and during customer acceptance testing.
6 REFERENCES
[ 1 ] Black Duck( 2025). BSIMM15 Report 2025. BSIMM Software Security Assessment Report | Black Duck
Journal of Innovation 11