Teknovelasta johtuvan haavoittuvuuden kautta tapahtuvan hyökkäyksen vai-kutukset voivat olla hyvin vakavia organisaatiolle niin taloudellisesti kuin muiltakin osin (esim. maine, markkinaosuus, asiakaskato). Vaikka teknovelan takaisinmaksu voi aiheuttaa kustannuspaineita, tulisi mahdollisesti haavoittu-vuuksia aiheuttavat teknovelan esiintymät priorisoida kehitystyössä korjatta-viksi ensimmäisenä (Izurieta ym., 2018). Jotta tässä voidaan onnistua, tulee käy-tettävän teknovelan hallintamenetelmän ottaa huomioon velasta seuraavat tur-vallisuusongelmat ja niiden vakavuus.
Rindell ja Holvitie (2019) ehdottavat turvallisuusvelan hallintaan uutta menetelmää, joka perustuu aiempaan teknovelan hallintaviitekehykseen. Sen ero olemassa oleviin metodeihin syntyy sen sisältämästä turvallisuusriskien arviointiprosessista, joka vaikuttaa kehityskohteiden priorisointiin. Hallinta-menetelmä pyrkii myös tekemään niin kutsutun turvallisuusvelan hallinnasta helpommin lähestyttävää teknovelan termistön kautta, sillä se on ennestään tuttua kehittäjille (Rindell & Holvitie, 2019).
Teknovelan hallinnalla voi olla myönteinen vaikutus ohjelmiston turvalli-suuteen. Ohjelmistojen turvallisuusheikkoudet voivat paljastua nopeammin teknovelan hallinnan seurauksena sen sijaan, että ne jäisivät piiloon. Tämä on erityisen tärkeää, sillä mitä kauemmin turvallisuusheikkous säilyy ohjelmistos-sa paikkaamattomana, sitä todennäköisemmin se muuttuu oikeaksi haavoittu-vuudeksi. Quocomo-laatumallia yhdessä haavoittuvuuksien nimeämistandar-din (Common Vulnerabilities and Exposures, CVE) sekä niiden vakavuuden määrittämismallin (Common Vulnerability Scoring System, CVSS) kanssa on
nantes & Serrano, 2016). SecDevOpsissa tämä ilmenee kehittäjien ja kyberhyök-käysten kanssa työskentelevien operatiivisten käyttäjien jatkuvalla yhteistyöllä.
Teknovelkaa ohjelmistoturvallisuuden näkökulmasta käsitteleviä hallin-tametodeja tieteellisiä julkaisuita ei ole julkaistu montaa. Ala vaikuttaa kuiten-kin kehittyvän jatkuvasti, sillä teknovelan ja ohjelmistoturvallisuuden yhteyttä on alettu tutkia ilmeisesti vastikään tässäkin tutkielmassa esiintyvien artikke-leiden tuoreuden perusteella.
Ohjelmistojen turvallisuutta koskevaa teknovelkaa (turvallisuusvelka) voidaan ajatella huomattavasti korkeamman riskin sijoituksena, kuin muita teknovelan muotoja. Pahimmassa tapauksessa sen riski voi realisoitua yhtäkki-sesti ja kokonaisuudessaan esimerkiksi erityisen pahan hyökkäyksen kautta.
Tällöin velka ei kuitenkaan poistu, vaan on yhä läsnä ohjelmistossa. Teknove-lasta aiheutunut turvallisuusongelma on kuitenkin realisoitunut, jolloin tästä aiheutuvaa kustannusta voidaan pitää osana velan korkoa. Lisärasitteen tuovat hyökkääjän vahingolliset tarkoitusperät, jonka vuoksi hyökkääjä on mahdolli-sesti saanut haltuunsa tietoja kohdeorganisaatioista tai muuten mahdollimahdolli-sesti saavuttanut hyökkäyksensä tavoitteet. Realisoituneen turvallisuusongelman korjaaminen ja vaikutusten minimointi voi olla kallista, minkä lisäksi olemassa oleva velka jatkaa koron kerryttämistä.
5 Yhteenveto ja pohdinta
Teknovelan metafora tarjoaa aiheesta kiinnostuneelle monipuolisia näkökulmia ohjelmistojen korjausvelasta. Terminä teknovelka on moniulotteinen, ja sen tut-kimus on aktiivista (Li ym., 2015). Teknovelan termistä on yhteisymmärrys abstraktilla tasolla, mutta sen tarkat piirteet sekä yhtenäinen määritelmä puut-tuvat. Hyvä esimerkki tästä on vikojen ja teknovelan kiistanalainen suhde.
Kruchtenin ym. (2012) artikkelissa viat jätetään teknovelan ulkopuolelle, mutta Alvesin ym. (2016) kartoitustutkimuksessa vikavelka nimetään yhdeksi ylei-simmistä teknovelan tyypeistä. Vikojen tuominen teknovelan metaforaan on yleistä etenkin ohjelmistoturvallisuuteen liittyvissä artikkeleissa. Rindell ym.
(2019) kertovat teknovelan koron tarkoittavan ohjelmiston käyttäjien kokemaa huonontunutta laatua. Tämä on myös ristiriidassa monen teknovelan määritel-mää koskevan artikkelin, kuten Bellomon ym. (2016), Kruchtenin ym. (2012) sekä Woodsin ym. (2018) kanssa.
Teknovelka toimii kattokäsitteenä useille teknovelan alatyypeille, joilla on omia erityispiirteitä esimerkiksi ohjelmiston arkkitehtuuriin tai koodin laadun suhteen (Kruchten ym., 2012). Loppujen lopuksi teknovelalla on kuitenkin sen tyypistä riippumatta vaikutuksia kahteen asiaan: aikaan sekä kustannuksiin.
Organisaatiot kerryttävät teknovelkaa tietoisesti lähinnä nopeuttaakseen ohjel-miston kehitystyötä hetkellisesti (Wehaibi ym., 2016). Siitä saatavat hyödyt kui-tenkin menetetään, jos teknovelkaa ei hallita asianmukaisesti (Bellomo ym., 2016). Teknovelkaiset ohjelmistot ovat hankalammin muutettavissa, mikä tekee niiden jatkokehityksestä vaikeaa (Tom ym., 2013). Ongelmallisen ohjelmiston kehittäminen vie kehittäjiltä enemmän aikaa, joka johtaa suurempiin kustan-nuksiin (Buschmann, 2011; Fairley & Willshire, 2017; Martini, Antonio ym., 2018; Peters, 2014; Woods, 2018). Teknovelan kanssa työskenteleminen voi myös turhauttaa kehittäjiä, koska sen kertyminen on lähes aina tietoinen päätös ja siksi myös estettävissä (Holvitie ym., 2014). Tämä vaatii kuitenkin tietoista paneutumista teknovelkaan ja sen hallintaan (Kruchten ym., 2012).
Teknovelan hallintaan on olemassa runsaasti erilaisia metodeja ja työkalu-ja, jotka pyrkivät helpottamaan sen tunnistamista, priorisointia tai hallintaa yleisesti (Fontana ym., 2016; Khomyakov ym., 2020; Yli-Huumo, 2016).
Tek-harhaanjohtaviksi niiden tulosten huonon laadun tai muiden puutteiden vuoksi.
Ne eivät myöskään kykene hahmottamaan ohjelmistoista arkkitehtuurillista teknovelkaa yhtä luotettavasti kuin koodivelkaa (Ernst ym., 2015; Khomyakov ym., 2020).
Erilaisia käsityksiä teknovelan hallitsemisesta, piirteistä ja tunnistamisesta löytyy runsaasti, mutta case-tutkimukset, joissa näitä toimia tarkastellaan oi-keissa organisaatioissa eivät mainitse aiemmin tutkimuksessa esiin nousseita metodeja. Tutkimuksissa kehitetyt metodit päätyvät hyvin harvoin käyttöön oikeisiin ympäristöihin tutkimusmaailman ulkopuolelle, mikä selviää myös Yli-Huumon (2016) sekä Lin ym. (2015) tutkimuksista. Tutkimuksen ja organisaa-tioiden käytännön toiminnan välillä on siis kuilu, jonka Siponen ja Baskerville (2018) ovat tunnistaneet yleiseksi ongelmaksi koko tietojärjestelmätieteen alan tutkimuksessa. Myös Tom ym. (2013) esittävät, kuinka käsitys teknovelan luon-teesta vaihtelee akateemisen ja oikean maailman ympäristöjen välillä. Voidaan siis sanoa, että teknovelan tutkimus kärsii samasta ilmiöstä kuin tietojärjestel-mätieteen tutkimus yleisesti.
Luulen että informaatiokatkokselle tutkimuksen ja oikeiden käyttöympä-ristöjen välillä teknovelan suhteen on erilaisia syitä. Yhtenä merkittävimmistä luulen olevan sen, ettei tutkimusten menetelmiä ilmeisesti kaupallisteta, sillä niitä ei ole käytössä oikeissa käyttöympäristöissä. Voi olla, että oikeissa käyt-töympäristöissä on kehitetty omia teknovelan hallintatyökaluja, jotka on räätä-löity huomioimaan tiettyjä ohjelmiston ja ympäristön piirteitä. Voisi kuvitella, että tarve hyvin kustomoiduille hallintamenetelmille korostuu ohjelmistoissa, joiden ymmärtäminen on hankalaa ihmisille, saati teknisille työkaluille. Organi-saatiot voivat myös olla pimennossa kaupallisten teknovelan hallintatyökalujen ja -menetelmien saatavuuden ja toimivuuden suhteen, mikä voi osaltaan selit-tää perinteisempien backlog-työkalujen tämänhetkistä suosiota teknovelan hal-linnassa.
Ohjelmistoturvallisuuden sekä teknovelan suhde kiteytyy ohjelmiston teknovelan ja sen laadun yhteyteen. Aiheesta ei ole julkaistu runsaasti tutki-musta, mutta tässäkin tutkielmassa aihetta käsittelevät artikkelit ovat hyvinkin tuoreita, mikä osoittaa aiheen ajankohtaisuuden. Yleinen käsitys on, että tekno-velka ei sinällään tarkoita uhkia ohjelmistoturvallisuuden kannalta, mutta kos-ka se pitää sisällään monia ohjelmistojen yleisiä laatuongelmia, korreloi sen määrä haavoittuvuuksien määrän kanssa (Siavvas ym., 2019). Kuten
teknove-lankin kertymisessä, aiheuttavat aikataulupaineet riskin myös turvallisuuson-gelmien kasaantumiselle. Lisäksi jos teknovelkaa poistetaan ohjelmistosta, voi se avata uusia haavoittuvuuksia (Nord ym., 2016).
Vastoin omia alkuperäisiä odotuksia teknovelka voi kuitenkin myös aut-taa ohjelmiston turvallisuuden kehittämisessä, koska teknovelan hallinta voi paljastaa turvallisuuspuutteita (Izurieta ym., 2018). Voidaankin sanoa, että kun teknovelkaa maksetaan takaisin, on sillä usein positiivinen vaikutus ohjelmis-ton turvallisuuteen.
Teknovelan ja ohjelmistoturvallisuuden suhde on noussut tutkimuksen aiheeksi vastikään. Pidän tätä pääsyynä teknovelasta aiheutuvien turvallisuus-ongelmien hallintametodien vähäiselle määrälle. Toinen mahdollinen syy tälle on nykyisten ohjelmistoturvallisuuden ja laadunhallinnan metodien riittävyys.
Tällöin tarvetta teknovelkaan erikoistumiselle ei välttämättä ole. Jos turvalli-suusvelan hallintametodeja esittäviä tutkimuksia kuitenkin ilmestyy, olisi toi-vottavaa, ettei tutkimus vajoaisi samaan sudenkuoppaan menetelmien pirstaloi-tumisen suhteen kuin alkuperäinen teknovelan hallintametodien tutkimus.
Suuri osa tässä tutkielmassa käsitellyistä artikkeleista käytti teknovelan tarkastelun lähteenä avoimen lähdekoodin ohjelmistoprojektien koodikantoja.
Yksi mahdollinen jatkotutkimuksen aihe olisi ilmeneekö teknovelka erilaisena erilaisissa ohjelmistoprojekteissa, kuten avoimen ja suljetun lähdekoodin pro-jekteissa. Teknovelka yhteisöllistetyissä (crowdsourced) ohjelmistokehitysjekteissa ja sen eroavaisuuksien vertailu suljetun ja avoimen lähdekoodin pro-jekteihin tarjoaisi myös mielenkiintoisen kohteen jatkotutkimukselle. Lisäksi teknovelan kertymisen ja tyypin vertailu erilaisissa organisaatioissa voisi tuot-taa lisätietoa sitä kerryttävistä toimintatavoista. Teknovelan ilmeneminen eten-kin startup-ympäristössä tarjoaisi erityisen kiehtovan ympäristön tutkimukselle niiden yleisesti suuremmista yrityksistä poikkeavan toimintakulttuurin vuoksi.
Tässä tutkielmassa on tarkasteltu teknovelkaa lähinnä teknisestä näkö-kulmasta. Samanlainen kirjallisuuskatsaus tämän metaforan vaikutuksesta or-ganisaatioiden liiketoimintaan voisi myös tuottaa mielenkiintoisia tuloksia.
Tässä tutkielmassa todetut vaikutukset ovat toki merkittäviä liiketoiminnan kannalta, mutta tarkempi syventyminen teknovelkaa kerryttäviin liiketoimin-taprosesseihin, niiden vaikutuksiin velan syntyyn ja hallintaan, tai esimerkiksi teknovelan kertyminen tietynlaisen johtamiskulttuurin tai liiketoimintastrategi-an seurauksena toisivat kenties erilaisia näkökulmia aiheeseen. Laajempaa mit-takaavaa ajatellen Magnusson, Juiz, Gomez ja Bermejo (2018) ovat laajentaneet teknovelan metaforaa koskemaan koko organisaatioiden IT:tä teknologiavelka-termillään.
Teknovelalla on etu moniin muihin alan termeihin verrattuna, sillä sen si-sältämä viittaus taloudelliseen velkaan tekee siitä helposti ymmärrettävän. On mielestäni erikoista, ettei metaforaan ole kohdistunut laajempaa mielenkiintoa jo aiemmin. Tämän työn ohjaajan sanoja mukaillen onkin mahdollista, että tek-novelan metafora tarvitsisi samanlaisen nostattavan tekijän, kuin mikä agile manifesto oli ketterille ohjelmistokehitysmenetelmille.
tematic mapping study. Information and Software Technology, 70, (s. 100-121).
doi:10.1016/j.infsof.2015.10.008
Amanatidis, T. (2017). Who is producing more technical debt?: A personalized assessment of TD principal. Proceedings of the Scientific Workshops of XP2017 ACM. doi:10.1145/3120459.3120464
Bellomo, S., Nord, R. L., Ozkaya, I. & Popeck, M. (2016). Got technical debt?
surfacing elusive technical debt in issue trackers. (s. 327-338) 2016
IEEE/ACM 13th Working Conference on Mining Software Repositories (MSR) ACM.
Besker, T., Martini, A. & Bosch, J. (2019a). How regulations of safety-critical software affect technical debt. (s. 74-81) 2019 45th Euromicro Conference on Software Engineering and Advanced Applications (SEAA) IEEE.
doi:10.1109/SEAA.2019.00020
Besker, T., Martini, A. & Bosch, J. (2019b). Technical debt triage in backlog ma-nagement. (s. 13-22) Proceedings of the Second International Conference on tech-nical debt IEEE Press. doi:10.1109/TechDebt.2019.00010
Brown, N., Cai, Y., Guo, Y., Kazman, R., Kim, M., Kruchten, P., . . . Zazworka, N.
(2010). Managing technical debt in software-reliant systems. (s. 47-52) Pro-ceedings of the FSE/SDP workshop on future of software engineering research ACM. doi:10.1145/1882362.1882373
Buschmann, F. (2011). To pay or not to pay technical debt. IEEE Software, 28(6), (s. 29-31). doi:10.1109/MS.2011.150
Codabux, Z., Williams, B. J. & Niu, N. (2014). A quality assurance approach to technical debt. Proceedings of the International Conference on Software Enginee-ring Research and Practice (SERP), , (s. 1). Haettu osoitteesta
https://search.proquest.com/docview/1649692284
Cunningham, W. (1992). The WyCash portfolio management system. (s. 29-30) Addendum to the proceedings on object-oriented programming systems, languages, and applications (addendum) ACM. doi:10.1145/157709.157715
de Jesus, J. S. & de Melo, A. C. V. (2017). Technical debt and the software project characteristics. A repository-based exploratory analysis. (s. 444-453) 2017 IEEE 19th Conference on Business Informatics (CBI) IEEE.
doi:10.1109/CBI.2017.62
Ebert, C., Gallardo, G., Hernantes, J. & Serrano, N. (2016). DevOps. IEEE Softwa-re, 33(3), (s. 94-100). doi:10.1109/MS.2016.68
Ernst, N. A., Bellomo, S., Ozkaya, I., Nord, R. L. & Gorton, I. (2015). Measure it?
manage it? ignore it? software practitioners and technical debt. Bergamo, Italy, (s. 50–60) Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering Association for Computing Machinery.
doi:10.1145/2786805.2786848
Fairley, R. E. & Willshire, M. J. (2017). Better now than later: Managing technical debt in systems development. Computer, 50(5), (s. 80-87).
doi:10.1109/MC.2017.124
Fernandez-Sanchez, C., Garbajosa, J., Vidal, C. & Yague, A. (2015). An analysis of techniques and methods for technical debt management: A reflection from the architecture perspective. (s. 22-28) 2015 IEEE/ACM 2nd Internati-onal Workshop on Software Architecture and Metrics IEEE.
doi:10.1109/SAM.2015.11
Fontana, F., Mangiacavalli, M., Pochiero, D. & Zanoni, M. (2015). On experi-menting refactoring tools to remove code smells. (s. 1-8) Scientific Workshop Proceedings of the XP2015 ACM. doi:10.1145/2764979.2764986
Fontana, F., Roveda, R. & Zanoni, M. (2016). Technical debt indexes provided by tools: A preliminary discussion. (s. 28-31) 2016 IEEE 8th International Workshop on Managing Technical Debt (MTD) IEEE.
doi:10.1109/MTD.2016.11
Holvitie, J., Leppanen, V. & Hyrynsalmi, S. (2014). Technical debt and the effect of agile software development practices on it - an industry practitioner sur-vey. (s. 35-42) 2014 Sixth International Workshop on Managing Technical Debt IEEE. doi:10.1109/MTD.2014.8
Izurieta, C. & Prouty, M. (2019). Leveraging secdevops to tackle the technical debt associated with cybersecurity attack tactics. (s. 33-37) Proceedings of the Second International Conference on technical debt IEEE Press.
doi:10.1109/TechDebt.2019.00012
Angelis, L. (2017). Technical debt principal assessment through structural metrics. (s. 329-333) 2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA) IEEE. doi:10.1109/SEAA.2017.59
Kruchten, P., Nord, R. L. & Ozkaya, I. (2012). Technical debt: From metaphor to theory and practice. IEEE Software, 29(6), (s. 18-21).
doi:10.1109/MS.2012.167
Letouzey, J. & Ilkiewicz, M. (2012). Managing technical debt with the SQALE method. IEEE Software, 29(6), (s. 44-51). doi:10.1109/MS.2012.129
Li, Z., Avgeriou, P. & Liang, P. (2015). A systematic mapping study on technical debt and its management. The Journal of Systems & Software, 101, (s. 193-220).
doi:10.1016/j.jss.2014.12.027
Lim, E., Taksande, N. & Seaman, C. (2012). A balancing act: What software practitioners have to say about technical debt. IEEE Software, 29(6), (s. 22-27). doi:10.1109/MS.2012.130
Magnusson, J., Juiz, C., Gómez, B. & Bermejo, B. (2018). Governing technology debt. (s. 76-84) Proceedings of the 2018 International Conference on technical debt ACM. doi:10.1145/3194164.3194169
Martini, A., Bosch, J. & Chaudron, M. (2014). Architecture technical debt: Un-derstanding causes and a qualitative model. (s. 85-92). 2015 12th Working IEEE/IFIP Conference on Software Architecture: 2014 40th EUROMICRO Conference on Software Engineering and Advanced Applications IEEE.
doi:10.1109/SEAA.2014.65
Martini, A., Besker, T. & Bosch, J. (2018). Technical debt tracking: Current state of practice; A survey and multiple case study in 15 large organizations.
Science of Computer Programming, 163, (s. 42). doi:10.1016/j.scico.2018.03.007 McGraw, G. (2012). Software security. Datenschutz Und Datensicherheit - DuD,
36(9), (s. 662-665). doi:10.1007/s11623-012-0222-3
Murat, E. & Pierre, P. (2016). Chapter 4 - evolving the architecture. Continuous architecture (s. 63-101) Elsevier Inc. doi:10.1016/B978-0-12-803284-8.00004-X Nord, R. L., Ozkaya, I., Schwartz, E. J., Shull, F. & Kazman, R. (2016). Can
knowledge of technical debt help identify software vulnerabilities? 9th Workshop on Cyber Security Experimentation and Test (CSET 2016) USENIX Association.
Peters, L. (2014). Technical debt: The ultimate antipattern - the biggest costs may be hidden, widespread, and long term. (s. 8-10) 2014 Sixth International Workshop on Managing Technical Debt IEEE. doi:10.1109/MTD.2014.7
Rafeh, R. & Rabiee, A. (2013). Towards the design of safety-critical software.
Journal of Applied Research and Technology, 11(5), (s. 683-694).
doi:10.1016/S1665-6423(13)71576-1
Rindell, K., Bernsmed, K. & Jaatun, M. G. (2019). Managing security in software:
Or: How I learned to stop worrying and manage the security technical debt.
Canterbury, CA, United Kingdom, Proceedings of the 14th International Confe-rence on Availability, Reliability and Security Association for Computing Machinery. doi:10.1145/3339252.3340338
Rindell, K. & Holvitie, J. (2019). Security risk assessment and management as technical debt. (s. 1-8) 2019 International Conference on Cyber Security and Pro-tection of Digital Services (Cyber Security) IEEE.
doi:10.1109/CyberSecPODS.2019.8885100
Rios, N., Mendonça Neto, Manoel Gomes de & Spínola, R. O. (2018). A tertiary study on technical debt: Types, management strategies, research trends, and base information for practitioners. Information and Software Technology, 102, (s. 117-145). doi:10.1016/j.infsof.2018.05.010
Rios, N., Oliveira Spinola, R., de Mendonca Neto, Manoel G & Seaman, C.
(2018). A study of factors that lead development teams to incur technical debt in software projects. (s. 429-436) 2018 44th Euromicro Conference on Software Engineering and Advanced Applications (SEAA) IEEE.
doi:10.1109/SEAA.2018.00076
Siavvas, M., Tsoukalas, D., Janković, M., Kehagias, D., Chatzigeorgiou, A., Tzo-varas, D., . . . Gelenbe, E. (2019). An empirical evaluation of the relationship between technical debt and software security.ICIST 2019 Proceedings Vol.1, (s. 199-203). doi:10.13140/RG.2.2.15488.79365
Siponen, M. & Baskerville, R. (2018). Intervention effect rates as a path to re-search relevance: Information systems security example. Journal of the
Asso-The MITRE Corporation. (1999). CVE - common vulnerabilities and exposures . Haettu osoitteesta https://cve.mitre.org/
Tom, E., Aurum, A. & Vidgen, R. (2013). An exploration of technical debt. The Journal of Systems & Software, 86(6), (s. 1498-1516).
doi:10.1016/j.jss.2012.12.052
Tufano, M. (2017). When and why your code starts to smell bad (and whether the smells go away). IEEE Transactions on Software Engineering, 43(11), (s.
1063-1088). doi:10.1109/TSE.2017.2653105
Turvallisuuskomitea. (2018). Kyberturvallisuuden sanasto. (s. 15) Sanastokes-kus TSK ry.
Wehaibi, S., Shihab, E. & Guerrouj, L. (2016). Examining the impact of self-admitted technical debt on software quality. (s. 179-188) 2016 IEEE 23rd In-ternational Conference on Software Analysis, Evolution, and Reengineering (SA-NER) IEEE. doi:10.1109/SANER.2016.72
Woods, E. (2018). The past, present and future of technical debt. (s. 61) Procee-dings of the 2018 International Conference on technical debt ACM.
doi:10.1145/3194164.3194181
Yli-Huumo, J. (2016). How do software development teams manage technical debt? – an empirical study. The Journal of Systems & Software, 120, (s. 195-218). doi:10.1016/j.jss.2016.05.018